mysql 主从复制 读写分离 MHA

mysql 的主从复制和读写分离：

读写分离和MHA高可用的前提 主从复制

主从复制的模式：

1.mysql的默认模式
异步模式：主库在更新完事务之后会立即把结果返回给从服务器，不关心从库是否接收到，是否处理成功
网络问题可能没有同步，或者是其他因素的影响导致同步失败。
快, 效率高

2.全同步模式：
主库在更新完事务之后，立即把结果返回到从库，所有的从库执行完之后才能继续下一个同步。安全，但性能低

3.半同步复制模式
介于异步和全同步之间，主库更新完事务，也是同步到从库，同步完之后有一个等待时间
等待时间是一个tcp/ip的往返时间 5ms左右
既一定程度上保证效率，又在一定程度上保证了数据的完整性

主从复制：主可以复制给从，从不能到主 也不能从到从

主从复制的延迟怎么解决：
1.网络问题：网线 路由器 防火墙的原因
2.硬件设备问题：cpu 内存 磁盘 出问题
3.配置文件 写错

配置文件中进行设置来提高数据的安全性。

前提 数据的存储引擎是innodb cat /etc/my.cnf 才行

双一设置：
innodb_flush_log_at_trx_commit=1
每次提交都会刷新事务日志，确保事务的持久性。但会影响性能
sync_binlog=1
每次提交事务，将二进制日志的内容保存到磁盘，确保日志的持久性。提高安全性

性能化设置：

sync_binlog=5 或10 0 极端情况 不建议
最多提交几条事务会进行磁盘刷新 日志内容保存到磁盘

innodb_flush_log_at_trx_commit=2
每次更新都保存在内存中，不进行刷新。

innodb_buffer_pool_size=60M
控制innodb缓冲池的大小,增大可以提高数据库的性能，但占用的是系统内存，配置时要注意合理化时间。

主从复制如何实现

主服务器记录数据变更到binlog，从服务器请求并复制这些变更到中继日志，然后执行以同步数据。异步过程，提升性能与可靠性
基于mysql的二进制日志，根据主库的二进制文件的标志位，实现主从同步。

主从服务器之间，服务器的时间要同步
架构：一主两从 三台服务器
192.168.233.21 mysql8.0主
192.168.233.22 mysql8.0从
192.168.233.23 mysql8.0从

log- slave-updates=true
允许 从服务器 从主库复制数据时，可以写入 从库 自己的二进制日志中
relay-log=relay-log-bin
从服务器上获取二进制日志的开头，开启从库的二进制日志
relay-log-index=slave-relay-bin.index
二进制日志的索引文件的名称
relay_log_recovery=1
配置从服务器 在启动使是否执行二进制日志的回复操作（和主库同步），1表示开启
Slave_IO_Running
从库和主机的读写通信是否正常
Slave_SQL_Running
slave mysql进程状态是否正常

读写分离：

前提是主从复制
在主从架构中，主库只负责写（数据写在主库，主从复制到从），从库只负责读

读写分离的方式：

1.代码 开发人员 使用代码完成，涉及到数据库的二次开发。性能好，不需要额外硬件设备

2.中间层代理 代理服务器。在客户端和主从架构之间有一个代理服务器。代理服务器收到客户端的请求之后，通过客户端的sql语句来进行判断，读转到从，写转到主

amoeba:读写分离最常用客户端代理软件。java代码开发的
192.168.233.21 mysql8.0主
192.168.233.22 mysql8.0从
192.168.233.23 mysql8.0从
192.168.233.10 jdk1.6和amoeba
192.168.233.20 maridb

MHA高可用

高可用模式下的故障切换，基于主从复制。
单点故障和主从复制不能切换的问题。
至少需要三台
故障切换过程 0-30秒
vip地址，根据vip地址所在的主机，确定主备

主和备不是优先确定的，主从复制的时候就确定了主,备是在MHA的过程中确定。
MHA的组件:
MHA NODE数据节点,每台mysql和管理服务器都要安装 监控服务器状态以及收集数据
MHA的manager管理节点
管理mysql的高可用集群
可以单独部署在一台独立的服务器，也可以部署多个
实现主备之间切换。主发生故障。切换到备。

MHA特点：
1.manager来实现主备切换
2.数据同步还是依靠二进制日志，最大程度保证数据不丢失
3.半同步方式，实现数据的完整性
一主多从的架构，最少三台

架构：
4台
master 192.168.235.21 mysql 8.0 node组件
slave1 192.168.235.22 mysql 8.0 node组件
slave2 192.168.235.23 mysql 8.0 node组件
管理节点 192.168.23.10 node组件 manager组件

masterha_check_ssh
所有的数据库节点和管理节点通过ssh来进行互相通信，检查集群的ssh配置
masterha_check_repl
检查mysql的复制情况 数据同步
masterha_manager
manager启动脚本
masterha_check_status
检查MHA集群状态的文件
masterha_master_switch
控制故障转移
masterha_stop
关闭manager服务

master_ip_failover自动故障切换时, vip的管理脚本
master_ip_online_change 在线切换时vip的管理脚本
power_manager故障发生后，关闭主机的脚本
send_report 故障切换之后，发送报警的脚本

在 manager 节点上测试 ssh 无密码认证
masterha_check_ssh -conf=/etc/masterha/app1.cnf

在 manager 节点上测试 mysql 主从连接情况
masterha_check_repl -conf=/etc/masterha/app1.cnf

在 manager 节点上启动 MHA
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null >
/var/log/masterha/app1/manager.log 2>&1 &

查看 MHA 状态，可以看到当前的 master 是 master 节点。
masterha_check_status --conf=/etc/masterha/app1.cnf

查看 MHA 日志，也以看到当前的 master 是 192.168.233.21，如下所示。
cat /var/log/masterha/app1/manager.log | grep “current master”

原文地址：https://blog.csdn.net/qq_64410777/article/details/140665645

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！