mysql如何查看主从复制状态

说白了，可以使用SHOW SLAVE STATUS命令查看MySQL主从复制的状态，配合一些辅助命令就可以做到。

随着我们的扩展，有几个关键点需要关注： 我们先来说说最重要的Slave_IO_Running和Slave_SQL_Running。
这两个必须显示“是”。
对于我们去年跑的百万层项目来说，如果这两个不活跃的话，排查网络丢包、用户权限、主库日志bin变更等问题会比其他任何事情都困难。
另一个需要注意的点是Seconds_Behind_Master。
我们的一个从库突然出现了5 分钟的延迟。
后来我们发现主库执行了几百G的导入操作。
很多人没有注意到这一点。
还有另一个关键细节。
如果Last_Error不为空，则需要快速查看日志。
去年，由于主键冲突，复制崩溃了，花了半天时间才解决。

起初我以为这只是查看延迟的问题，但后来我发现这是错误的。
即使是完整的从数据库 CPU 也会减慢该过程，尤其是对于缓慢的、未优化的查询。

建议用脚本定期运行这些命令，并尽快处理异常，而不是等待业务错误报告后再救火。

mysql一主多从,主库宕机,如何合理切换到从库

如果单主MySQL多从架构的主库崩溃，必须立即切换到从库。
这些事情可大可小。
说实话，我当时不知道该怎么办。
现在回想起来，主要有以下几个步骤：
首先检查从库数据同步状态。
这需要执行一个名为stopslaveio_thread的命令；在所有从库上停止 IO 线程。
然后，使用showslavestatusG；命令查看 Slave_SQL_Running_State 必须显示“Slave 已读取所有中继日志；正在等待更多更新”。
这意味着从库已经同步了主库的所有数据。

接下来，您需要选择一个新的主库。
这就需要比较所有从库的Relay_Master_Log_File和Exec_Master_Log_Pos参数的两个值。
一般情况下，数值最大的两个从库成为新的主库。
如果两个值相等，则选择其中一个即可。

选择新的主库后，下一步就是将其提升为主库。
必须先执行stopslave；对选定的从库执行命令来停止复制过程。
然后，使用resetslaveall；重置所有复制的信息。
记得将全局只读属性设置为0并使用setglobal read-only=0;。
最后执行resetmaster；命令重置二进制日志。
再次使用showmasterstatus查看新主库的状态，验证一切正常。

还必须考虑自动切换机制，这是保证服务可用性和数据一致性的关键。
可以建立自动切换机制，通过监控主库的状态来触发切换过程。

注意：需要监控并解决主从同步延迟问题。
这可能是由于网络延迟或数据库性能不足造成的。
确保转换过程顺利进行，不会发生任何导致数据不一致的情况。

最后，优化网络配置、提高从库性能、分散主库负载等都可以提高系统整体的稳定性和性能。
这件事看似简单，但处理起来却要小心。
毕竟，如果你不小心，你就必须重新开始。

MySQL 主从，5 分钟带你掌握

哎呀，说到MySQL主从面试题，问题真是五花八门啊。
记得有一次面试的时候面试官问我：MySQL主从复制的原理是什么？当时没考虑到，所以就粗略的说了，主要是靠binlog，记录所有的变化，然后从主库推送到辅库。
面试官听后没有说什么，所以我感觉有点困惑。

还有一次，面试官问我，主从延迟怎么解决？我当时就说了，主要是监控从库的滞后时间，如果滞后太大就报警。
面试官又问，有没有具体的方法来减少延迟？我刚才说可以优化SQL语句，减少锁等待，或者提高从库的I/O性能。

还有一次，面试官问我，如果主库故障，如何切换到从库？刚才讲了两种情况，一种是单主多从，一种是多主多从。
单主多从是指主库故障，从库接管；多主多从是指主库故障，其他从库接管。

我记得另一次采访。
面试官问我，binlog格式是什么？我回答说有三种，指令式、线式和混合式。
面试官又问，这三种格式有什么区别？我只想说，statement记录的是SQL语句，row记录的是行数据，mixed是两者的结合。

说实话，MySQL主从面试确实需要好好准备。
就像楼哥在面试小米的时候，把主从复制的原理和延迟的解决方案解释得很好，给面试官留下了很好的印象。
然而，对于像我这样的初学者来说，有时还是觉得很困难。
然而，通过更多的练习，你应该能够逐渐开始。