试图理解MySQL中的显示从状态
我有一个主-从复制设置，它看起来是运行良好。以下是SHOW SLAVE STATUS命令的结果：
show slave STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: *.*.*.*
Master_User: repliV1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 10726644
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 231871
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: data1
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 10726644
Relay_Log_Space: 232172
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:我想进一步了解Relay_Log_File，Relay_Log_Pos和Relay_Master_Log_File。
我的问题是：
- 中继日志文件是在本地读取和存储以便运行复制的文件，这是真的吗？
- 那么
relay_master_log_file呢?它与Master_Log_File有什么不同？ - 这两个值都是什么，即
Read_Master_Log_Pos和Relay_Log_Pos？为什么即使复制已经完成并保持同步，它们仍然会出现？ - 这些文件是二进制格式的，因此我无法查看它们，这是真的吗？
回答 3
Database Administration用户
发布于 2012-05-26 11:06:31
我想进一步了解的是Relay_Log_File，Relay_Log_Pos和Relay_Master_Log_File。
从SHOW SLAVE STATUS\G获得两个值
Relay_Log_File：当前中继日志在复制期间接受新条目Relay_Log_Pos：当前中继日志在复制期间接受新条目的当前位置Relay_Master_Log_File：中继日志文件，其中包含在主服务器上执行的最后一次成功执行的SQL语句。- Master_Log_File :母版上的日志，对应于当前中继日志文件和当前中继日志位置
这些文件是二进制文件，因此无法正确地查看它们。
是的，你可以查看中继日志。由于它们具有与常规二进制日志相同的结构，所以只需运行mysqlbinlog程序即可。例如，要在中继日志(如最后一个日志)中查看SQL，请执行以下操作：
mysqlbinlog mysqld-relay-bin.000056 > /root/SQLForCurrentRelayLog.txt
less /root/SQLForCurrentRelayLog.txtDatabase Administration用户
发布于 2012-05-29 21:29:09
Relay_Master_Log_File实际上是主服务器上包含在从服务器上成功执行的最后一个SQL语句的binlog的名称。它不是从服务器上的中继日志的名称。请参阅：http://dev.mysql.com/doc/refman/5.5/en/show-slave-status.html
Exec_Master_Log_Pos是从SQL线程执行到的relay_master_log_file中的位置。因此，在您的示例中，从db一直执行所有语句，直到主db上的binlog mysql-bin.000001 pos 10726644。
只有当您使用语法until_log_pos启动从属程序时，才会真正使用START SLAVE UNTIL master_log_pos = $integer。这个语法将复制到那个位置(它将是exec_master_log_pos)，然后停止。通常只有当您想要复制到特定的点时才会这样做，而不需要做进一步的复制(比如下一条语句是一个偶然的表下降或什么的)。当未指定until_log_pos值时，它的值为0，因此在您的示例中，这意味着复制将继续前进。
Database Administration用户
发布于 2023-03-22 02:30:28
若要确定与从机当前逻辑状态对应的主服务器上的binlog文件名/位置对，请使用Relay_ master _Log_ file /Exec_Master_Log_Pos。我为参数的混乱名称道歉，这些名称发生在复制的早期(MySQL版本3.23/4.0)。最初，我们只有一个从线程读取事件并立即应用它们。然后Jeremy指出，如果主程序在奴隶运行很长时间更新时永久死亡，这种体系结构可能会导致严重的数据丢失，因此我们实现了他对中继日志的建议。现在，我用对我有意义的名字命名了新变量，没有人反对，代码被发布了，然后我们不得不坚持最初选择的名称，这是因为我们对向后兼容性的强烈承诺。回想起来，Relay_Master_Log_File可能应该是Exec_Master_Log_File，Master_Log_File应该是Read_Master_Log_File。
https://dba.stackexchange.com/questions/18433
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号