>> Simon wrote: >> >>>>> It looks like we have reached the Max_data_length for the >>>>> dbmail_messageblks table, this is currently 4294967295 (which is 4GB >>>>> im gussing - which is about right). From the mysql docs, this can be >>>>> easliery solved by running: >>>>> >>>>> ALTER TABLE tbl_name MAX_ROWS=1000000000 AVG_ROW_LENGTH=nnn;
S> For those who are interested, i have solved this in a different way S> (thanks Mark!). The above ALTER would have taken quite an amount of time S> (downtime) to solve doing it either a ALTER or dumping the data then S> reimporting after the ALTER. The way i did it, only took DBMail offline S> for 5 mins, have testing on development and all works with no issues S> (that i can see - any other thoughts here?): S> Shut down DBMail... S> RENAME TABLE dbmail_messageblks TO dbmail_messageblks_part1; S> CREATE TABLE dbmail_messageblks_part2 ( S> messageblk_idnr bigint(21) NOT NULL auto_increment, S> physmessage_id bigint(21) DEFAULT '0' NOT NULL, S> messageblk longtext NOT NULL, S> blocksize bigint(21) DEFAULT '0' NOT NULL, S> is_header tinyint(1) DEFAULT '0' NOT NULL, S> PRIMARY KEY (messageblk_idnr), S> INDEX physmessage_id_index (physmessage_id), S> INDEX physmessage_id_is_header_index (physmessage_id, is_header) S> ); S> CREATE TABLE dbmail_messageblks ( S> messageblk_idnr bigint(21) NOT NULL auto_increment, S> physmessage_id bigint(21) DEFAULT '0' NOT NULL, S> messageblk longtext NOT NULL, S> blocksize bigint(21) DEFAULT '0' NOT NULL, S> is_header tinyint(1) DEFAULT '0' NOT NULL, S> PRIMARY KEY (messageblk_idnr), S> INDEX physmessage_id_index (physmessage_id), S> INDEX physmessage_id_is_header_index (physmessage_id, is_header) S> ) TYPE=MERGE UNION(dbmail_messageblks_part1, dbmail_messageblks_part2) S> INSERT_METHOD=LAST; S> Start DBMail with your MTA disabled and test delivery with: S> echo -e "Subject: test\nFrom: [EMAIL PROTECTED] \n\n" | dbmail-smtp -u S> username It's rather interesting decision. I wonder is it real to build something like an array of merged dbmail_messageblks_partX tables? In previous maillists I have asked about big dbmail_messageblks table (now it's around 50Gb) and there was no decision to make OPTIMIZE TABLE dbmail_messageblks because of it's locking for a long time. As I understand we can make 10 or X number of dbmail_messageblks tables and we shall be able to make OPTIMIZE of each table separately. What do you think about it?
