mysql高可用
2022-06-13 20:44:00 0 举报AI智能生成
mysql高可用
作者其他创作
大纲/内容
主从复制
同步
master节点接收用户的写请求，并写入到binlog中，Slave上执行sart slave命令开启主从复制开关
slave通过一个IO线程与master建立连接，发送binlog dump指令
master服务器接收到来自slave服务器的IO线程的请求后，其上负责复制的IO线程会根据slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给slave端的IO线程
当slave服务器的IO线程获取到master服务器上的IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写道slave端自身的relay log（中继日志）文件的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时，能告诉master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
slave通过另一个线程sql thread应用本地的relay log，将数据同步到slave库中
常见问题及处理方案
数据丢失
如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了
5.6开启半同步复制（semi-sync复制）
主库写入binlog日志之后，就将强制此时立即将数据同步到从库，从库写入到自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为是写操作完成了
可以设置超时间，等待一定的时间后从库未返回结果，降级未异步同步
主从同步延迟问题
原因
大事务，导致同步慢
化大事务为小事务
控制每个事务操作的量，如删除很多数据时，分成多次删除
sql语句操作的数量较大
垂直拆表
大表DDL
借助第三方工具机型ddl操作 pt-online-schema-change
建立一张新表，进行表结构修改操作
操作完毕后将原始表中的数据同步到新表，分批操作
同步完成之后修改名字并将原始表删除
网络传输延迟
master节点挂载过多的slave节点
一般不要超过5个
主从服务器配置不一样
从服务器承担过多的读操作
show status 查看主从同步延时
对于一些强一致性的业务场景，要求插入后必须能读取到，强制读请求走主库
考虑是否需要拆表，将大表拆分为小表，提供同步效率
修改代码逻辑，不要插了就查，直接update
sql上加入特殊标识，代理层解析
/*master*/select * from table
开发专门访问主库的查询api
sleep方案
事务问题
事务中的所有sql统一都走主库，由于只涉及一个库，本地事务就可以搞定
双M复制
节点A和B之间总是互为主备关系，这样咋切换的时候就不用修改主备关系
规定两个库的server id必须不同，如果相同，则他们之间不能设定为主备关系
一个备库连接到binlog并在重放的过程中，生成与原binlog的server id相同的新的binlog
每个库在收到从自己的主库发过来的日志后，先判断server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志
双M可以设置各自的id自增加步长不一样，让一个库的自增id为奇数，另一个库的自增id为偶数，避免两个库生成的主键发生冲突
MGR复制
在原来的基于日志的复制中，从服务器连接到主服务器并告诉主服务器要从那个二进制日志的偏移量开始执行增量同步，这时我们如果指定的日志偏移量不对，这可能会造成主从数据不一致，二基于GTID的复制会避免
什么是GTID，也就是全局事务ID，其保证为每一个在主服务器上提交的事务在复制集群中可以生成一个唯一的ID
一个GTID由两个部分组成的，分别是source_id和transaction_id，GTID=source_id:transaction_id，其中source_id就是执行事务的主库的server-uuid值，server-uuid值是在mysql服务首次启动的时候生成的，保存在数据库的数据目录中，在数据目录中有一个auto.conf文件，这个文件保存了server-uuid的值（唯一的）。而事务ID则是从1开始自增的序列，表示这个事务是在主库上执行的第几个事务，Mysql会保证这个事务和GTID是一比一的关系
在基于GTID的复制中，首先从服务器会告诉从服务器执行完了哪些事务的GTID值，然后主库会把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库执行一次，这样可以避免由于偏移量的问题造成数据不一致。
高可用架构
原理
对主从复制集群中的master节点进行监控
master节点不可用后，修改vip指向新的master节点，客户端直连vip
配置集群中的其他slave节点同步新的master节点
MHA
架构
一个master节点
2到n个从节点
操作
主服务器宕机后，选举具有最新更新的slave节点
尝试从宕机的master中保存binlog
应用差异的中继relay_log到其他slave节点
将从master保存的binlog应用到这个salve节点中
提升这个slave节点作为新的master作为新的master节点，将vip指向这个master节点
配置其他slave节点去新的master节点同步数据
优缺点
支持GTID主从复制
可以从多个slave节点中选择最合适的节点作为新的master
尽可能减少丢失事务
会尝试从宕机的master中尽可能多的保存为同步的日志
尽可能减少丢失事务
需要自行开发vip迁移脚本
只监控master节点的监控，没有对slave节点进行监控和高可用
0 条评论
下一页
