☰

将拥有自己的从属服务器的 MySQL 从属服务器提升为主服务器

tag-icon • tag-icon mysql mysql-replication mysql-cluster
将拥有自己的从属服务器的 MySQL 从属服务器提升为主服务器

MySQL 待机和链式复制

具有当前设置（不使用 GTID）（参见图像链接）：

  • 生产节点：主节点（A）->从节点（A1）+从节点（A2）
  • 备用节点：-> 从属（B）（启用 log_slave_updates）-> 从属（B1）+ 从属（B2）

如果主 MASTER (A) 发生故障，备用节点将被提升为主生产节点。因此，如果 MASTER (A) 发生故障，我们希望将 SLAVE (B) 提升为主节点并取消所有 (A) 节点。因此，我们计划针对此场景使用以下命令：

  • MASTER（A）发生故障，无法恢复
  • 从属（B）执行：STOP SLAVE和RESET MASTER；
  • 从属（B1，B2）执行：STOP SLAVE，，RESET SLAVE；START SLAVE

它是否正确？

答案1

在我所做的所有复制更改中，我从未使用过RESET。我不知道它到底起什么作用，也不知道是否有必要使用它。

我认为没有必要向 B 或 B1 和 B2 发出任何命令，除了做任何需要改变的事情客户将 B 视为主要。（我假设您关闭了readonlyB？

至于如何利用 A1 和 A2，这比较棘手。启用 GTID 后，应该可以让它们弄清楚如何从 B 进行复制。如果没有 GTID，克隆 B1 或 B2 可能比弄清楚 binlog/relaylog 定位更方便。

（将来，dba.stackexchange.com 将会成为一个更好的解决这类问题的网站。）

相关内容