错误写入mysql从服务器

发布于 2024-12-12 13:40:14 字数 512 浏览 1 评论 0原文

我的mysql复制设置为一主一从。由于代码中的错误,在中间的某个地方,条目开始写入从属服务器上,并在几天后被检测到。 现在我正在考虑如何正确地切换它,而不会有任何麻烦或最少的停机时间,最好的方法是什么?让我们只考虑一张表...

解决方案1

​​只需将auto_increment设置为slave的最后一个id后,从现在开始写入master即可。想知道master和slave不同步会不会很麻烦。

解决方案2

清除 master 中的所有数据,停止应用程序使用 mysqldump 进行更多条目重新填充数据,然后使用正确的配置重新打开应用程序。

stop slave
// load the dump
start slave

这会阻止主设备重新尝试向从设备写入相同的数据吗?

任何帮助表示赞赏。也欢迎任何其他解决方案。

谢谢 苏希尔

I have mysql replication set up with one master and one slave. Due to a bug in the code, somewhere in the middle the entries started to get written on slave server and it was detected a few days later on.
Now I am thinking of how to switch it correctly without any hassle or minimal down time, what would be the best way to do this? Lets consider only one table...

Solution 1

Simply start writing to master from now on after setting auto_increment to slave's last id. Wondering if it will be troublesome to keep master and slave out of sync.

Solution 2

Clear all the data from master, stop the app from making any more entries refill the data using mysqldump and then switching the app back on with correct config.

stop slave
// load the dump
start slave

Will this stop master from re-attempting to write to slave the same data?

Any help appreciated. Any other solutions also welcomed.

Thanks
Sushil

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

蓝礼 2024-12-19 13:40:14

我认为您的解决方案 2 是正确的。简单地停止从属服务器不会阻止主服务器写入其二进制日志。因此,当您再次启动从属服务器时,它只会复制主服务器上的所有 SQL 语句。

但是,如果您在创建每个表之前包含“DROP TABLE”,则可以利用此优势。这意味着您需要执行以下操作:

1) 停止应用程序在主表中添加更多条目

2) 从从属表转储数据(确保 mysqldump 在每个表之前包含“DROP TABLE”)表导入 - 它应该这样做,因为它是 mysqldump 的默认选项)

3) 针对 master 运行转储

4) 使用 SHOW SLAVE STATUS\G 检查从属状态。一旦 Seconds_Behind_Master 达到 0,那么您就可以再次打开应用程序(确保它正在写入主站!!)

第 3 步将使用来自从站的数据删除并重新创建主站上的表。此删除和重新创建将被复制到从属设备上,因此您最终应该使两者同步并设置正确的主从设备。

祝你好运!

I think you are on the correct track with solution 2. Simply stopping the slave will not prevent the master from writing to it's binary log. So when you start the slave again it will just replicate all the SQL statements from the master.

However, you can use this to your advantage if you have included 'DROP TABLE' before each table creation. This will mean that you have the following:

1) Stop the app from making any more entries in the master table(s)

2) Dump data from slave (ensure that mysqldump includes 'DROP TABLE' before each table import - it should do as it is a default option of mysqldump)

3) Run dump against master

4) Check slave status using SHOW SLAVE STATUS\G. Once Seconds_Behind_Master reaches 0 then you are good to switch on the app again (make sure it is writing to the master!!)

Step 3 will drop and recreate the tables on the master using the data from the slave. This drop and recreate will be replicated on to the slave so you should end up with the two in sync and a correct master slave set up.

Good luck!

心的位置 2024-12-19 13:40:14

我认为你最好的选择是完全重置从站/主站。如果从站上的数据正确,则重新加载其中的数据,然后从主站导出新的转储并将其导入到从站,然后执行新的“CHANGE MASTER TO...”命令,

我建议设置“read_only” “从站上的全局变量。

http://dev.mysql.com /doc/refman/5.1/en/replication-options-slave.html#option_mysqld_read-only

I think your best option is to reset the slave/master completely. If the data on the slave is correct reload the data from it and then export export a new dump from the master and import it to the slave, then execute a new "CHANGE MASTER TO..." command

I would recommend setting the "read_only" global variable on the slave.

http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_read-only

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文