We are setting up a replicated slave from a MySQL database running 5.6.37. The slave is running the exact same version. All tables use InnoDB as engine. Mysqldump is invoked with:
mysqldump –master-data –routines –single-transaction –skip-lock-tables –databases db_1 db_2
We have two databases that should be replicated.
After reading documentation and following examples found when searching, this is the command that should be used for a live database. Specifically, –skip-lock-tables, to avoid a global read lock, though such a lock is acquired for the master data.
After restoring the slave with this backup and doing the necessary to connect to the master, we start seeing differences compared to master. Almost immediately we receive a write error due to primary key already being in use (autogenerated id). Via manual inspection, we also see rows in a table X on the slave, that are not present in master.
We use ROW as binlog format.
What these errors have in common is that the affected tables are tables that are purely written by triggers, either directly or indirectly via a stored procedure (called by a trigger).
For example, by checking timestamps that we store, I can determine that the rows we see in table X on the slave, that are not present on the master, were inserted during the time mysqldump was running. They are no longer present on the master as these rows are quickly deleted (poor man’s queue; one process inserts, another processes and deletes). So the rows were inserted after mysqldump was started, but are still available in the dump. But the rows are also deleted during the dump, but these removals never reach the slave via the replicated binlogs. Likewise, the error with primary key was also a write performed when the mysqldump was running.
It therefore feels that the usage of triggers to perform inserts doesn’t play well with –single-transaction, though that ought to be the expected behaviour(?). Am I wrong in this conclusion, or is it even possible that this MySQL version has known bugs? Again, all tables are InnoDB, no MyIASM. Other than that I don’t know what configuration could create this behaviour.
Next step would be to run mysqldump without –skip-lock-tables to create a global read lock. However, as that would effectively disable our database for about an hour, the live approach is obviously much preferred.
✓ Extra quality
ExtraProxies brings the best proxy quality for you with our private and reliable proxies
✓ Extra anonymity
Top level of anonymity and 100% safe proxies – this is what you get with every proxy package
✓ Extra speed
1,ooo mb/s proxy servers speed – we are way better than others – just enjoy our proxies!
USA proxy location
We offer premium quality USA private proxies – the most essential proxies you can ever want from USA
Our proxies have TOP level of anonymity + Elite quality, so you are always safe and secure with your proxies
Use your proxies as much as you want – we have no limits for data transfer and bandwidth, unlimited usage!
Superb fast proxy servers with 1,000 mb/s speed – sit back and enjoy your lightning fast private proxies!
99,9% servers uptime
Alive and working proxies all the time – we are taking care of our servers so you can use them without any problems
No usage restrictions
You have freedom to use your proxies with every software, browser or website you want without restrictions
Perfect for SEO
We are 100% friendly with all SEO tasks as well as internet marketing – feel the power with our proxies
Buy more proxies and get better price – we offer various proxy packages with great deals and discounts
We are working 24/7 to bring the best proxy experience for you – we are glad to help and assist you!