[MDEV-2562] LP:714419 - Replication failures with slave provisioning via mysqldump and tables with no PK Created: 2011-02-07 Updated: 2015-04-13 Resolved: 2012-10-04 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Philip Stoev (Inactive) | Assignee: | Kristian Nielsen |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | Launchpad | ||
| Attachments: |
LPexportBug714419.xml
LPexportBug714419_bug714419.yy
LPexportBug714419_bug714419.zz
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
The following test fails in mysql 5.1, maria-5.2 and maria-5.2-rpl, but passes under mysql 5.5 . The test operates as follows: 1. A transactional concurrent UPDATE workload is maintained on the master throughout the test; 2. Around the middle of the test, a new slave is provisioned via mysqldump (port 19304, datadir and logs in mysql-test/var/master-data_clonedslave) and then started; 3. At the end of the test, the new slave is checked via SHOW SLAVE STATUS and dumped and compared to the master There is a separate slave, on port 19304 that is not provisioned via mysqldump. It replicates properly and is not relevant to this particular bug ) The slave reports either: 110207 9:04:37 [ERROR] Slave SQL: Error 'Table 'test.table1_innodb_int' doesn't exist' on opening tables, Error_code: 1146 even though the table does exist on the slave and the workload does not contain any DDL statements or 110207 9:37:17 [ERROR] Slave SQL: Could not execute Update_rows event on table test.table100_innodb; Can't find record in 'table100_innodb', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's master log master-bin.000001, end_log_pos 7833035, Error_code: 1032 This issue seems to be releated to the more general problem of replicating tables with no PK, even though in this particular test, straightforward replication does work – what does not work is provisioning a new slave via mysqldump. Extensive fixes for PK-less replication were done for 5.5 . |
| Comments |
| Comment by Philip Stoev (Inactive) [ 2011-02-07 ] |
|
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload |
| Comment by Philip Stoev (Inactive) [ 2011-02-07 ] |
|
ZZ file |
| Comment by Philip Stoev (Inactive) [ 2011-02-07 ] |
|
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload |
| Comment by Philip Stoev (Inactive) [ 2011-02-07 ] |
|
YY file |
| Comment by Philip Stoev (Inactive) [ 2011-02-07 ] |
|
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload perl runall.pl \ |
| Comment by Kristian Nielsen [ 2011-02-07 ] |
|
Re: Replication failures with slave provisioning via mysqldump and tables with no PK I started manually the cloned slave after the failure in the master-data_clonedslave directory like this: cd mysql-test/var/master-data_clonedslave /home/knielsen/my/5.2/work-5.2-rpl/sql/mysqld --no-defaults --datadir=$(pwd) --character-sets-dir=/home/knielsen/my/5.2/work-5.2-rpl/sql/share/charsets --language=/home/knielsen/my/5.2/work-5.2-rpl/sql/share/english/ --skip-slave-start --relay-log=clonedslave-relay It fails on this query (in my particular case): /* QUERY_IS_REPLICATION_SAFE */ UPDATE `table1_innodb` SET `col_varchar_255_utf8` = REPEAT(LPAD(CONNECTION_ID(), 2, ' '), 2 ) , `col_bigint` = REPEAT(LPAD(CONNECTION_ID(), 2, ' '), 3 ) What I see is that the row-based update event corresponding to this has the value 1212121212121212 for column `col_double_key`. While the table on the cloned slave has the value 1212121212121210. This causes the event to fail to apply. I think this is a fundamental problem with using mysqldump to save and restore floating-point numbers. The problem is that the textual decimal representation used by mysqldump is not precise: > select col_double_key from table1_innodb; 1.21212121212121e+15 This output is not precise enough to distinguish the two different values on the master and cloned slave. In MySQL 5.5 they use a better library for printing floating-point numbers. Maybe that provides a textual decimal representation for mysqldump with sufficient precision, which could be the reason the bug is not reproducible there. I do not think we should fix this in 5.1/5.2. A work-around to get the RQG test to not fail could be to only use values for double columns which are integers with at most 14 digits, as I believe the textual decimal representation is precise for such numbers. |
| Comment by Rasmus Johansson (Inactive) [ 2011-02-07 ] |
|
Launchpad bug id: 714419 |