【问题标题】:What actually gets replicated to a MySQL slave?什么实际上被复制到 MySQL 从站?
【发布时间】:2011-03-13 21:12:01
【问题描述】:

我在多主复制设置中配置了两台 MySQL 服务器。每个人都是对方的奴隶和主人。我的应用程序要求在后台运行一些大型查询,这些查询的结果将用于填充表。我想,我可以让这些大型查询在一台服务器上运行,而应用程序前端使用另一台服务器。这样,当服务器运行这些查询时,应用程序就不会变慢。

这些查询非常大INSERT .... SELECT。使用我的复制设置,似乎当一台服务器完成查询时,它不仅仅是将 INSERT 发送到从属服务器,而是让从属服务器运行原始的大型 INSERT/SELECT。

这真的发生了吗?或者有没有办法查看从主机发送到从机的命令来验证这是行为?我能判断的唯一方法是 CPU 负载。

有没有办法让从属只从一个 INSERT... SELECT 获得结果 INSERT 在主控上运行?

【问题讨论】:

    标签: mysql replication database-replication


    【解决方案1】:

    这真的发生了吗?

    大概吧。

    或者有没有办法查看从主设备向从设备发送了哪些命令来验证这是行为?

    嗯,你可以 deconstruct the binlog,但我希望阅读replication format options 不会那么令人头疼。

    您可能处于基于语句的模式,这是多年来的默认设置。如果这些 INSERT INTO ... SELECT 语句很麻烦,您希望处于 基于行的模式混合模式。这些选项仅在 MySQL 5.1 或更高版本中可用。

    【讨论】:

    • 关于基于行的复制的警告:生成的二进制日志通常比基于语句的大很多。
    • 您可以使用诸如 mytop 之类的工具来显示在 MASTER 和 SLAVE 上运行的查询。也可以直接运行 SHOW PROCESSLIST;在基于语句和基于行之间需要权衡取舍。我想写这些,但上面的链接是足够好的阅读材料。
    【解决方案2】:

    运行实际查询。解决您 INSERT...SELECT 的唯一方法是自己分解它们。运行选择,将结果存储在内存中,然后进行批量插入。

    【讨论】:

      猜你喜欢
      • 2014-07-14
      • 2013-01-10
      • 2021-09-17
      • 1970-01-01
      • 1970-01-01
      • 2019-11-15
      • 1970-01-01
      • 2022-09-22
      • 2019-10-31
      相关资源
      最近更新 更多