3

we are using Percona 5.7.16-10 server. I would like to expand current solution with XtraDB cluster. So meanwhile I created other machines and started cluster (running on 5.7.17-11-57 Percona XtraDB Cluster version) and I did some testing there (everything seems to be working fine). Now I would like to dump current database from running server and insert it into cluster. There is no problem to stop the cluster (since it is for testing). But when I create mysqldump as I was used to, I'm not able to insert it into cluster because of pcx_strict_mode (info here) - with enforcing Percona-XtraDB-Cluster prohibits use of LOCK TABLE/FLUSH TABLE <table> WITH READ LOCK with pxc_strict_mode = ENFORCING because the mysqldump creates script which contains table lock which is prohibited. So I've tested several more options, like MASTER which should don't check this rule, but it didn't help, because the insert query from the dump get stuck and nothing is happening.

Is there any mysqldump option to avoid table locking queries, or do I have to restore it somehow via XtraBackup and use XtraBackup for current running server?

I've read several topics here, but didn't match anyone with the same issue. Everyone is solving how to restore cluster from some fail, not from the scratch.

I will be glad for any suggestion for mysqldump or what is proper way to "insert" old database into cluster.

Radim
  • 164
  • 1
  • 4
  • 18

1 Answers1

7

If you can take down your current machine, and if you are building the cluster from scratch, then I think these (on mysqldump) would avoid that strict_mode, and possibly some other hiccups:

--skip_add_locks --skip-lock-tables

And do not use

--single-transaction --lock-all-tables

It might also be wise to get the first node in the cluster loaded with the data, then add on the other nodes, letting them use SST to load themselves.

If you need to keep the current server alive, then we need to discuss making it a Master and one node of the new cluster be a Slave. Plus XtraBackup would probably be better suited. But now, the locks and single-transaction would be necessary. So setting that strict_mode to DISABLED seems right since the cluster is being built, and not yet live.

(Caveat: I have no experience performing your task; if someone else provides a more convincing Answer, go with them.)

Rick James
  • 135,179
  • 13
  • 127
  • 222
  • Thank you! Not sure what happened during my last try, but as you supposed, to set strict_mode to DISABLED, worked for the second try (I must have done some mistake before). For some future readers I did the regular dump with --single-transaction on, then restart cluster with DISABLED mode and restore the DB (st on just because I was pulling some live data for testing). As soon as it will be available I will give you bounty, thanks! – Radim Apr 10 '17 at 06:44