1、MySQL复制功能提供分担读负载
复制解决了什么问题?
1、 实现在不同服务器上的数据分布
利用二进制日志增量进行
不需要太多的带宽
但是使用基于行的复制在进行大批量的更改时会对带宽带来一定的压力
特别是跨IDC环境下进行复制应该分批进行。
2、实现数据读取的负载均衡
需要其他组件配合完成
利用DNS轮询的方式把程序的读连接到不同的备份
使用LVS,haproxy这样的代理方式
非共享架构,同样的数据分布在多台服务器上
3、增加了数据的安全性
利用备库的备份来减少主库负载
复制并不能代替备份
方便进行数据库高可用架构的部署,避免MySQL单点失败
4、实现数据库高可用和故障切换
5、实现数据库在线升级
2、MySQL二进制日志
二进制日志:记录了所有对MySQL数据库的修改事件,包括增删改查事件和对表结构的修改事件
二进制日志的格式:
基于段的日志格式:binlog_format=STATEMENT
优点:1、日志记录量相对较小,节约磁盘及网络I/O
2、只对一条记录修改或者插入
3、row格式所产生的日志量小于段产生的日志量
缺点:1、必须要记录上下文信息,保证语句在从服务器上执行结果和在主服务器上相同
2、特定函数UUID(),user()这样非确定性函数还是无法复制,可能造成MySQL复制的主备服务器数据不一致
基于行的日志格式:binlog_format=ROW
ROW格式可以避免MySQL复制中出现主从不一致问题
优点:1、使用MySQL主从复制更加安全
2、对每一行数据的修改比基于段的复制高效
缺点:记录日志量较大
混合日志格式:binlog_format=MIXED
特点:根据SQL语句由系统决在基于段和基于行的日志格式中进行选择
数据量的大小由所执行的SQL语句决定
3、MySQL复制工作方式
第一步:主将变更写入二进制日志
第二步:从读取二进制日志变更并写入到relay_log中
基于日志点的复制
基于GTID的复制
第三步:在从上重放relay_log中的日志
基于SQL段的日志是在从库上重新执行记录的SQL
基于行的日志则是在从库上直接应用对数据库行的修改
4、基于日志点的复制
操作步骤例子:
1、进行主服务器的环境中:
2、建立数据库用户:
3、授权用户:
4、退出
5、看看配置的参数
6、进行备份数据库
7、将备份的文件传到从服务器上
8、将文件导入到从数据库
9、在从数据库上进行复制链路的配置
10、看看从服务器
11、启动
12、看看主从上的进程
优点:
a、是MySQL最早支持的复制技术,Bug相对较少
b、对SQL查询没有任何限制
c、故障处理比较容易
缺点:
a、故障转移时重新获取新主的日志点信息比较困难
5、基于CTID的复制
什么时GTID?
GTID即全局事务ID,其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。
GTID=source_id:transaction_id
操作步骤例子:
1、进行主服务器的环境中:
2、建立数据库用户:
3、授权用户:
4、修改配置(主服务和从服务器)
5、重启服务器
6、初始化数据
7、查看all2.sql的内容
8、将备份的文件传到从服务器上
9、将文件导入到从数据库
10、在从数据库上进行复制链路的配置
11、启动
优点:
方便进行故障转移
从库不会丢失主库上的任何修改
缺点:
故障处理比较复杂
对执行的SQL有一定限制
选择复制模式考虑的问题
所使用的MYSQL版本(gtid是mysql5.6引入的新功能,早期的5.6版本也不建议使用gtid复制)
复制建构及主从切换的方式
所使用的高可用管理组建
对应用的支持程度