我们正在使用Percona 5.7.16-10服务器。我想用XtraDB集群扩展当前的解决方案。所以同时我创建了其他机器并启动了集群（运行在5.7.17-11-57 Percona XtraDB集群版本上），我在那里做了一些测试（一切似乎都运行正常）。现在我想从正在运行的服务器转储当前数据库并将其插入到集群中。停止集群没有问题（因为它是用于测试）。但是当我按照惯例创建mysqldump时，由于pcx_strict_mode（info here），我无法将其插入到集群中 - 强制执行Percona-XtraDB-Cluster prohibits use of LOCK TABLE/FLUSH TABLE <table> WITH READ LOCK with pxc_strict_mode = ENFORCING因为mysqldump创建了包含表锁的脚本被禁止。所以我测试了几个选项，比如MASTER，它不应该检查这个规则，但它没有帮助，因为来自转储的插入查询被卡住而且没有任何事情发生。
是否有任何mysqldump选项可以避免表锁定查询，或者我是否必须通过XtraBackup以某种方式还原它并将XtraBackup用于当前正在运行的服务器？
我已经阅读了几个主题here，但与同一问题的任何人都不匹配。每个人都在解决如何从一些失败中恢复集群，而不是从头开始。
对于mysqldump的任何建议或者将旧数据库“插入”群集的正确方法，我将很高兴。
答案 0 :(得分：2)
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.)