使用MYSQL复制来加速Schema更改和表优化
我听说许多人使用主从安排有助于缩短更改模式时所花费的时间，方法是使用复制来设置新的临时主服务器，然后停止重新定位，然后在重新开始之前交换角色。我在堆栈溢出中找到了一个示例（如下）。
- 设置从站
- 停止复制。
- 在从属设备上进行 ALTER
- 让奴隶追上主人
- 交换主服务器和从服务器，因此从服务器成为更改后的生产服务器 结构和最短停机时间
这一切都很好，但是，我不明白第 4 步，我不清楚。
我想知道是否有人可以更清楚地解释一下程序。
I hear that many people use master - slave arrangements help to improve time taken when changing schemas by using replication to setup a new temporary master, then stopping relocation and then swapping roles before starting again. I have found an example (below) found on stack overflow.
- Setup slave
- Stop replication.
- Make ALTER on slave
- Let slave catch up the master
- swap master and slave, so slave becomes production server with changed
structure and minimum downtime
This is all very well, however, i dont understand step 4 it isn't clear to me.
I wonder if anyone could please explain the procedure clearer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让从机赶上主机意味着从机落后主机 0 秒。
这意味着如果复制在某个时刻停止（供您更改表），
它将记录最后一次复制时间。
当复制恢复时，
它将比较主服务器上的当前写入与从服务器上的上次复制时间。
然而，该程序似乎存在缺陷。
你不能改变奴隶和
更新的从属中的期望架构与主控相同。
在事件中，列类型发生更改，列被删除，
可能会导致复制失败。
Let slave catch up with the master meaning slave is 0 seconds behind master.
This mean if the replication stopped at some point (for you to alter table),
it will register a last replication time.
When the replication resume,
it will compare the current write on master with the last replication time on slave.
However, the procedures seems to be a flaw.
You cannot alter slave and
expecting schema in the updated slave is same as master.
In the events column type changed, column dropped,
potentially lead to replication failure.
secondary_behind_master 应为 0。
seconds_behind_master should be 0.