数据库MySQL-复制

1. 复制

复制的本质是可以帮助MySQL分担读负载, 并不能实现写负载. MySQL的高可用可以为高可用, 灾难恢复, 备份提供了很多的选择.

MySQL的复制是基于主库上的binglog二进制日志来进行增量推送的, 所以在同一个时间内如果从主库写入数据, 然后快速的向从库读取数据是没有办法做到十分准时的

2. MySQL的复制解决了什么问题

• 实现了在不同服务器上的数据分布
  • 利用二进制的日志增量进行
  • 不需要太多的带宽
  • 但是使用基于行的复制在进行大批量的更改时会对贷款带来一定的压力
• 实现数据读取的负载均衡
  • 需要其他组件配合完成: 利用DNS轮询的方式把程序的读连接到不同的备份数据库, 使用LVS, haproxy这样的代理方式
• 增强了数据安全性(但是复制并不能代表备份, 因为主库上的修改往往会很快速的同步到从库上, 所以拿从库当数据备份是不可行的)
• 实现数据库高可用和故障切换
• 实现数据库的在线升级(使用一个高版本的数据库作为从库, 然后校验一段时间之后就会知道当前版本的数据库是否能够进行完美兼容)

1. MySQL日志

1.1 MySQL服务层日志

1. 二进制日志
2. 慢查日志
3. 通用日志

1.2 MySQL存储引擎层日志

1. innodb 的事务提交日志和回滚日志

二进制日志

纪录了所有对MySQL数据库的修改事件
包括增删改查时间和对表结构的修改事件

备注:binlog日志只会记录事务成功提交的日志, 未成功的不会存储

二进制日志的格式

• 基于段的格式 binlog_format = STATEMENT

1. 优点
   日志记录量相对较小, 节约磁盘以及网络I/O 只对一条记录修改或者插入, 那么基于row所产生的日志量会更小于段产生的日志量
2. 缺点
   必须要记录上下文环境

• 基于row的日志记录格式(目前MySQL5.7以后就默认使用这种格式, 避免了当使用user() 等一些特定函数时导致主从库数据不一致的问题)

基于段的日志格式与基于行的日志格式的区别

1. 同一SQL预计修改了1万条数据, 基于段只会记录这个SQL
2. 基于段的日志会记录1万条数据每一行的数据修改

二进制日志基于row格式的优点

3. 基于行的日志格式使得主从复制更加安全
4. 对每一行数据的修改比基于段的复制更加高效

当我们因为误操作修改了数据库中的数据, 同时有没有备份可以恢复时, 我们就可以通过分析二进制日志, 对日志中记录的数据修改操作做反向处理的方式来达到恢复数据的目的

二进制日志基于row格式的缺点

1. 记录日志量比较大, 到那时可以根据binlog_row_image = [FULL|MINIMAL|NOBLOB] 三种方式来决定我们要使用的日志记录的量有多大

混合日志格式 binlog_format = MIXED

特点:

• 根据SQL语句, 由系统来决定是基于段还是基于行的日志格式, 能使用段则用段, 不能则使用行
• 数据量大小由所执行的SQL语句决定

总结:
建议使用 binlog_format = mixed 混合日志格式或者是 binlog_format = row的形式 . 如果使用了行的格式, name需要配置一下binlog_row_image = minimal ,这样可以减少一些不必要的io操作 等于full时是不想管的字段update也会被记录, 使用minimal只会记录相关被update的方式