Details
-
Type:
Bug
-
Status: Closed
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
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
110207 9:04:37 [Warning] Slave: Table 'test.table1_innodb_int' doesn't exist 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 .
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Open
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload
YY file
LPexportBug714419_bug714419.yy
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload
Re: Replication failures with slave provisioning via mysqldump under UPDATE workload
To reproduce, branch a fresh version of RQG using "bzr branch lp:randgen" and then run:
perl runall.pl \
--gendata=bug714419.zz \
--rpl_mode=row \
--duration=60 \
--queries=1000000000 \
--threads=10 \
--validator=None \
--basedir=/home/philips/bzr/maria-5.2-rpl \
--engine=InnoDB \
-mysqld=-default-storage-engine=Innodb \
--grammar=bug714419.yy
--reporter=CloneSlave
Re: Replication failures with slave provisioning via mysqldump and tables with no PK
I managed to repeat locally, and investigated the issue.
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.
Launchpad bug id: 714419
ZZ file
LPexportBug714419_bug714419.zz