atxdba Asked: 2014-08-20 20:35:38 +0800 CST2014-08-20 20:35:38 +0800 CST 2014-08-20 20:35:38 +0800 CST mysql 5.6 gtid 复制:是否需要 log_slave_updates? 772 我读过文档说 log_slave_updates 是必需的。这对于一般的促销情况是有意义的。 但是,对于您打算成为永远不会被提升的只读奴隶的东西,这真的仍然需要吗? mysql 1 个回答 Voted Best Answer jynus 2014-08-21T00:47:20+08:002014-08-21T00:47:20+08:00 是的,使用 gtid 时必须设置,否则 mysql 将无法启动,为您提供以下错误: [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates 从站需要自己执行的二进制日志,以便在停止(例如,如果它崩溃)或主站更改(主站上的硬件发生故障而无法修复并且另一个从站正在运行)的情况下自动定位自己晋升为新奴隶),即使它自己永远不会成为主人。虽然我认为它可以在运行时专门控制在内存中,但我敢打赌它需要自己的二进制日志作为故障保护,以防崩溃。 你可能觉得这样很麻烦,但换来的就是不用再处理 binlog 文件和 binlog pos 地址了。此外,从属设备上的二进制日志总是一个好主意。如果大小是问题,您仍然可以自动清除它们。expire-logs-days/max-binlog-size并且在 5.6 中使用 group-commit,性能损失应该是最小的。我以前没有使用log_slave_updates过的另一件事(检查从属设备上没有写入)现在可以用gtid_executed值来控制。 简而言之,设置它,并且在大多数情况下不用担心。
是的,使用 gtid 时必须设置,否则 mysql 将无法启动,为您提供以下错误:
从站需要自己执行的二进制日志,以便在停止(例如,如果它崩溃)或主站更改(主站上的硬件发生故障而无法修复并且另一个从站正在运行)的情况下自动定位自己晋升为新奴隶),即使它自己永远不会成为主人。虽然我认为它可以在运行时专门控制在内存中,但我敢打赌它需要自己的二进制日志作为故障保护,以防崩溃。
你可能觉得这样很麻烦,但换来的就是不用再处理 binlog 文件和 binlog pos 地址了。此外,从属设备上的二进制日志总是一个好主意。如果大小是问题,您仍然可以自动清除它们。
expire-logs-days/max-binlog-size
并且在 5.6 中使用 group-commit,性能损失应该是最小的。我以前没有使用log_slave_updates
过的另一件事(检查从属设备上没有写入)现在可以用gtid_executed
值来控制。简而言之,设置它,并且在大多数情况下不用担心。