我们使用 Percona 5.7.16-10 服务器。我想用 XtraDB 集群扩展当前的解决方案。因此,同时我创建了其他机器并启动了集群(在 5.7.17-11-57 Percona XtraDB Cluster 版本上运行),并在那里做了一些测试(一切似乎都工作正常)。现在我想从正在运行的服务器转储当前数据库并将其插入集群。停止集群是没有问题的(因为是为了测试)。但是,当我按照习惯创建 mysqldump 时,由于 pcx_strict_mode (信息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 提供任何建议,或者将旧数据库“插入”集群的正确方法是什么。
如果您可以关闭当前的机器,并且如果您从头开始构建集群,那么我认为这些(在
mysqldump
上)将避免严格模式,并可能避免一些其他问题:
--skip_add_locks --skip-lock-tables
并且不要使用
--single-transaction --lock-all-tables
让集群中的第一个节点加载数据也可能是明智的,然后添加其他节点,让它们使用 SST 来加载自己。
如果需要保持当前服务器处于活动状态,那么我们需要讨论将其设为 Master,并将新集群的一个节点设为 Slave。另外,XtraBackup 可能更适合。但现在,锁和单事务是必要的。因此,将 strict_mode 设置为
DISABLED
似乎是正确的,因为集群正在构建,但尚未上线。
(警告:我没有执行您的任务的经验;如果其他人提供了更有说服力的答案,请跟随他们。)
您可以在导入期间将 pxc_strict_mode 设置为 PREMISSIVE,但这样您将不会捕获与锁定相关的错误。
set global pxc_strict_mode=PERMISSIVE;
完成后记得恢复模式
set global pxc_strict_mode=ENFORCING;