mysql主从复制

嗨咯沃得

已于 2022-09-24 23:24:39 修改

阅读量539

点赞数

分类专栏：数据库文章标签： mysql 服务器数据库

于 2022-09-24 23:24:20 首次发布

本文链接：https://blog.csdn.net/m0_46673598/article/details/127032497

版权

数据库专栏收录该内容

2 篇文章 0 订阅

订阅专栏

一、介绍

二、原理

三、主从复制的三种模式

四、实现基于binlog+position的异步主从复制

五、实现基于binlog+gtid的异步主从复制

六、手工实现主从故障切换方案

七、问题：

一、介绍

保证主和从服务器上的数据一致，主要用在数据分布、负载均衡、故障切换、升级测试等方面

1.数据备份：随意开始或停止复制，并在不同地理位置分布数据备份
2.负载均衡：降低单个服务器的压力
3.故障切换：帮助应用程序避免单点失败
4.升级测试：可以用更高版本的MySQL作为从库

二、原理

①当Master节点进行insert、update、delete操作时，会按顺序写入到binlog中。
②salve从库连接master主库，Master有多少个slave就会创建多少个binlog dump线程。
③当Master节点的binlog发生变化时，binlog dump 线程会通知所有的salve节点，并将相应的binlog内容推送给slave节点。
④I/O线程接收到 binlog 内容后，将内容写入到本地的 relay-log。
⑤SQL线程读取I/O线程写入的relay-log，并且根据 relay-log 的内容对从数据库做对应的操作。

三、主从复制的三种模式

异步模式(async-mode)mysql默认
这种模式下，主节点不会主动推送数据到从节点，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理。这样就会有一个问题了，主节点如果崩溃掉了，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。客户端速度快

半同步复制
和全同步不同的是，半同步复制的逻辑是这样，从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。

全同步复制
主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端，但是很显然这个方式的话性能会受到严重影响。

四、实现基于binlog+position的异步主从复制

主服务器上开启二进制功能，同时将原始数据备份，新建一个授权用户
开启二进制：my.cnf配置里的[mysqld]块下加入一行log_bin，再添加一行server_id=1
新建一个用户：create user 'screpl'@'192.168.50.89' identified by '123456sc';
授权：grant replication slave on *.* to 'screpl'@'192.168.50.89';
锁住主服务器上的所有表：flush tables with read lock;
查看logbin日志名和位置号：show master status;
生成备份文件：mysqldump -uroot -p123456 --all-databases --master-data > sc_dbdump.db;
将备份文件传给从服务器：scp sc_dbdump.db root@192.168.50.89:/opt
从服务器my.cnf配置里的[mysqld]块下添加一行server_id=2
从服务器全备份主的数据：mysql -uroot -p123456 <sc_dbdump.db
从服务器开启slave功能和主建立连接：
change master to master_host='192.168.50.88',
master_user='screpl',
master_password='123456sc',
master_port=3306,
master_log_file='mysql-master-bin.000002',
master_log_pos=3205;
从服务器start slave;启动
从服务器上show slave status\G;查看查看io和sql线程开启状态判断主从复制是否建立连接
主服务器上解开锁：unlock tables;

至此，主从同步完成，实现了异步同步

五、实现基于binlog+gtid的异步主从复制

主的配置：

从的配置：

在从上填写master的信息：

root@(none) 16:42  mysql>CHANGE MASTER TO MASTER_HOST='192.168.0.165' ,
    ->  MASTER_USER='sc_slave',
    ->  MASTER_PASSWORD='123456',
    ->  MASTER_PORT=3307,
    ->  master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

六、手工实现主从故障切换方案

1.什么时候需要主从切换，主从切换如何实现？
主服务器挂了，需要提升原来的从为主 --》主从切换
完全手工去操作：
步骤：
1.stop slave
2.reset master
3.开启二进制日志
4.建立授权复制的用户
5.再启动一台机器做从，配置master信息去拉取二进制日志
如何将网站的写的流量切到新的master上？
1.直接修改web里的代码里的ip，换成新的master的ip
2.修改域名对应的ip为新的master的ip
3.如果使用中间件，需要在中间件里调整

是否可以自动实现主从切换？
答案: 可以
使用脚本实现
1.监控master
在另外一台机器扫描端口：nc 3306
直接访问: mysql -h ip -uroot -p'**' -e 'show databases;'
每秒钟监控一次
2.马上执行手工操作的步骤，脚本自动执行

七、问题：

主从延迟如何解决

一、架构方面
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.不同业务的mysql物理上放在不同机器，分散压力。
5.使用比主库更好的硬件设备作为slave总结，mysql压力小，延迟自然会变小。

二、硬件方面
1.采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。
2.存储用ssd或者盘阵或者san，提升随机写的性能。
3.主从间保证处在同一个交换机下面，并且是万兆环境。

主库宕机问题

硬件问题我们可以查看IDC巡检记录，或通过远程控制卡查看硬件运行状态，根据事实情况就行硬件故障报修进行处理，恢复业务步骤：
1）查看报警信息，确认业务是否收到影响，必要时切从库进行数据交互
2）IDC询问排查
3）确认硬件故障，短时间无法修复开Case处理
4）通知部门领导，处理进度，并实时记录
5）事件处理完成后，拟写故障报告，会议通报

1.首先要做的就是判断是否影响业务，是否需要切库，保证业务运行时首要任务
2.对主库实现高可用，另一台库拉取宕机主库的数据
3.在主库编写备份脚本，及时备份到主机上