| Bug #41897 | Table events are no more collected for one table until we restart the mysqld | ||
|---|---|---|---|
| Submitted: | 6 Jan 2009 16:49 | Modified: | 23 May 2009 15:15 |
| Reporter: | Cyril SCETBON | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Cluster: Replication | Severity: | S2 (Serious) |
| Version: | mysql-5.1-telco-6.3 | OS: | Linux (debian etch) |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
| Tags: | cluster, mysql-5.1.27-telco-6.3.17, RBR, replication | ||
[16 Jan 2009 8:38]
Hartmut Holzgraefe
This sounds like a problem we recently fixed. This problem was still present in the 6.3.17 version you are currently using but is fixed in the current MySQL Cluster 6.3.20. Please check again with the current version to see whether it fixes the problem for you, too.
[16 Jan 2009 8:59]
Cyril SCETBON
can you give me the bug number ?
[16 Jan 2009 9:07]
Hartmut Holzgraefe
Bug #39404 "In a release build it will typically mean that a table stops logging. In a debug build there will be an assetion and a core"
[17 Feb 2009 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[1 Apr 2009 9:20]
Axel Schwenke
Same problem seen on a customer system: one of the binlogging SQL nodes in the master cluster suddenly stops logging events for a certain table. The other binlogging SQL node continues without a problem. This time we have a suspicious message in the mysqld error log: [NdbApi] ERROR -- dropped GSN_SUB_TABLE_DATA due to wrong magic number This looks like a communication problem between the cluster and the SQL node (packet garbled?) that should be fixed. Silently unsubscribing from data change events is not an option. Version: mysql-5.1.23-ndb-6.2.15
[23 Apr 2009 15:15]
Axel Schwenke
this is probably a duplicate of bug #39404 whoever is affected by this problem should upgrade to ndb-6.2.16 / ndb-6.3.18 or later and check if the problem is fixed
[23 May 2009 23:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
Description: We're using replication between 2 clusters. Events for one of our tables are no longer collected, whereas other events for other tables are logged in the binary logs (RBR) Restarting the mysqld daemon of the replication master node solved the problem and we see events appeared again in the binary logs as you can see : before restarting : ------------------- replication01[sophia][prod]:~# mysqlbinlog /SPP/data/replication01-bin.000002|grep map|awk -F"Table_map:" '{print $2}'|sort|uniq `spp`.`table1` mapped to number 29 `spp`.`table2` mapped to number 31 `spp`.`table3` mapped to number 30 after restarting : ------------------ replication01[sophia][prod]:~# mysqlbinlog /SPP/data/replication01-bin.000004|grep map|awk -F"Table_map:" '{print $2}'|sort|uniq `spp`.`table1` mapped to number 29 `spp`.`table0` mapped to number 28 <-------- it appears `spp`.`table2` mapped to number 31 `spp`.`table3` mapped to number 30 How to repeat: none Suggested fix: none