Bug #31391 Replication broken after few UPDATE on RAM disk only with mod_ndb
Submitted: 4 Oct 2007 9:46 Modified: 31 Jan 2008 8:21
Reporter: Nicolas Legrand Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S2 (Serious)
Version:5.1.20 OS:Linux (x86_64)
Assigned to: CPU Architecture:Any
Tags: Broken, disk, RAM, replication, table, UPDATE

[4 Oct 2007 9:46] Nicolas Legrand
Description:
We encountered several replication issues when trying to send UPDATE through mod-ndb on a RAM disk table. We have a 2 tables configuration, one in RAM and one on disk. Each Cluster have 4 nodes and 1 ndb_mgmd.

Massive insert are working on both table, but it seems that launching some UPDATE (sometimes less than 5), will break the replication with the following message:

         Last_SQL_Error: Error in Write_rows event: error during transaction execution on table mydb.mytable

This error apply only when the update command are sent from the mod_ndb apache module, and it will append if the update is on the same row (and /or the same update) and on different rows.

We've also discovered that the configuration was working without the in12 int(11) element, even if the update is not on in12.

How to repeat:
mysql> desc mytable;
+-------+---------------------+------+-----+-------------------+----------------+
| Field | Type                | Null | Key | Default           | Extra          |
+-------+---------------------+------+-----+-------------------+----------------+
| id    | bigint(20) unsigned | NO   | PRI | NULL              | auto_increment |
| ise   | varchar(54)         | NO   | UNI |                   |                |
| s01   | int(11)             | NO   |     | -1                |                |
| s02   | int(11)             | NO   |     | -1                |                |
| s03   | int(11)             | NO   |     | -1                |                |
| s04   | int(11)             | NO   |     | -1                |                |
| s05   | int(11)             | NO   |     | -1                |                |
| s06   | int(11)             | NO   |     | -1                |                |
| s07   | int(11)             | NO   |     | -1                |                |
| s08   | int(11)             | NO   |     | -1                |                |
| s09   | int(11)             | NO   |     | -1                |                |
| s10   | int(11)             | NO   |     | -1                |                |
| ut    | int(11)             | NO   |     | 6                 |                |
| act   | tinyint(1)          | NO   |     | 0                 |                |
| ts    | timestamp           | NO   |     | CURRENT_TIMESTAMP |                |
| in11  | int(11)             | NO   |     | -1                |                |
| in12  | int(11)             | NO   |     | -1                |                |
+-------+---------------------+------+-----+-------------------+----------------+
17 rows in set (0.00 sec)
[8 Oct 2007 9:06] Nicolas Legrand
After a lots of testings, the problem also occured on disk table.

The limitation is to have over 16 fields in your the table.

We upgraded to 5.1.22RC and did not find the problem anymore
[31 Jan 2008 5:37] Valeriy Kravchuk
So, the problem is not repeatable with 5.1.22. Correct me, if this is wrong statement.
[31 Jan 2008 8:21] Nicolas Legrand
You're correct, we've upgraded on 5.1.22-rc and currently no more issue on this particular topic. Thanks to all dev's!