如何使用TRUNCATE语句避免MySql将其写入binlog？
MySQL 似乎不支持 TRUNCATE 标志“NO_WRITE_TO_BINLOG”。 所以我必须等到延迟为0，然后停止复制，对表进行TRUNCATE，重置主服务器，然后再次开始复制。 真的很痛苦。 还有其他建议吗？
It seems MySQL does not support the flag "NO_ WRITE_ TO_ BINLOG" for TRUNCATE. So I have to wait until delay is 0, then stop the replication, make the TRUNCATE of the table/s, reset the master, and then start replication again. Really painful. Any other suggestion?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
TRUNCATE 是相当严厉的。 您可以只使用 DELETE 查询吗？
TRUNCATE is pretty heavy-handed. Can you get by with just a DELETE query?
您可以使用该命令禁用会话的二进制日志记录来执行您想要的操作。
这确实需要您具有 SUPER 权限，因为您通过不向从属设备发送 TRUNCATE 来有效地中断复制。
You can use the command to disable binary logging for a session to do what you want.
This does require that you have the SUPER privilege since you are effectively breaking replication by not sending the TRUNCATE to the slave.
TRUNCATE 不能轻易使用，因为它本质上只是将数据丢弃在地板上，而不记录它这样做的事实。 它在事务上不安全并且无法恢复，因此它与复制不兼容。 即使您设法在复制设置中使用 TRUNCATE，您的复制数据也将被损坏，或者充其量是无效的。
TRUNCATE is not to be used lightly, since it essentially just drops the data on the floor without logging the fact that it did it. It's transactionally unsafe and impossible to recover from, and as a result it's not compatible with replication. Even if you manage to use TRUNCATE in a replication setup, your replicated data will be corrupt, or at best invalid.