Comment 6 for bug 1267507

Hi Alex, Hi Seppo,

thank you for your answers.

1)
The Cluster is in testing-phase and therefore shouldn't be problem to test "your" binaries.

2)
Sorry, no, this is not possible. This data may not leave the company.

3)
The software itself is OTRS 3.2.8, the structure of the table is:

CREATE TABLE IF NOT EXISTS `article_attachment` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `article_id` bigint(20) NOT NULL,
  `filename` varchar(250) DEFAULT NULL,
  `content_size` varchar(30) DEFAULT NULL,
  `content_type` text,
  `content_id` varchar(250) DEFAULT NULL COMMENT 'bei Upgrade von 2.4 auf 3.0.11 von graz4u hinzugefügt',
  `content_alternative` varchar(50) DEFAULT NULL COMMENT 'bei Upgrade von 2.4 auf 3.0.11 von graz4u hinzugefügt',
  `content` longblob NOT NULL,
  `create_time` datetime NOT NULL,
  `create_by` int(11) NOT NULL,
  `change_time` datetime NOT NULL,
  `change_by` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `article_attachment_article_id` (`article_id`),
  KEY `create_by` (`create_by`),
  KEY `change_by` (`change_by`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=28344 ;

It should have 23076 rows, but it mostly crashes around 20233 (+/- 30) rows.

4) to round up the picure:
- first, the article table is filled. there are 9450187 rows, it is about 16.7 GByte large.
- second, the article_attachment table is done,23076 rows. it should be about 2 GByte large.

it always crashes at this table.

i will try to create a new export only of the article_attachments table, which i will try to import into the cluster.