MySQL学习(四)----MySQL的二进制文件和根据二进制文件实现主从复制

MySQL复制功能提供分担读负载
备库：分担读负载
高可用、灾难恢复、备份提供更多的选择

二进制日志
复制解决什么问题
实现在通天服务器的数据分布
利用二进制日志增量进行
不需要太多的带宽
但是使用基于行的复制在进行大批量的更改时
会对带宽带来一定的压力
特别是跨IDC环境下进行复制

解决什么问题
是现在不同服务器上的数据分布
实现数据读取的负载均衡
需要其他组件配合完成
利用DNS轮询的方式把程序的读连接到不同的备份数据库使用LVS、HAPROXY
这样的代理方式

复制解决了什么问题：
实现在不同服务器上的数据分布
实现数据读取的负载均衡
增强了数据安全性
实现数据库高可用和故障切换
实现数据库的在线升级

MYSQL启用和查看二进制日志
查看是否启用了日志
mysql>show variables like 'log_bin';
查看当前的日志
mysql> show master status;
看二进制日志文件用mysqlbinlog
shell>mysqlbinlog mail-bin.000001

二进制日志
MySQL服务层日志--二进制日志
MySQL存储引擎层日志--innodb重做日志、回滚日志

binlog查看二进制
二进制日志的格式
基于段的格式 binlog_format=STATMENT
有点：
日志记录量相对较小、节约磁盘及网络I/O(来源记录方式)
缺点：
必须要记录上下文信息--保证语句在冲服务器上执行结果和在主服务器上相同
特定函数如UUID(),user()这样非特定函数还是无法复制--有可能造成主备服务器数据不一致

查看格式:show variables like 'binlog_fromat' 

sqllog
查看MySQL日志:mysqlbinlog +日志名

基于行的日志格式binlog_format=ROW 5.6之后基于它的
同意SQL语句修改了10000条数据的情况下
基于段的日志格式智慧聚录这个SQL语句
基于行的日志会有10000条记录分别记录每一行

有点：Mysql主从复制更加安全
     对每一行数据的修改比基于段的复制高效

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

缺点：
记录日志量较大；5.6之后增加binlog_row_image=[FULL|MINIAL|NoBLOB]

混合日记格式mixed；
特点：
根据SQL语句由系统来决定和基于行的日志格式中进行选择
数据量大小有所执行的sql语句决定

建议选择mixed和row

MySQL复制工作方式:
1.主将变更写入二进制日志;
2.从读取主的而进驻日志变更并写入到relay_log中
3.在从上重放relay_log中的日志

基于日志点的复制
在主DB服务器上建立复制账号
CREATE USER ‘repl’@'ip段' identified by 'PassWord'；
GRANT REPLICATION SLAVE ON *.* TO 'repl' @'IP段'
bin_log=mysql-bin
server_id=100

从服务器配置:
bin_log=mysql-bin
server_id=101
relay_log=mysql_relay_bin
log_slave_update=on[可选]
read_only=on[可选]

初始化从服务器数据
mysqldump --master-data=2 -single-transaction

xtrabackup --slave-info

启动复制连路
CHANGE MASTER TO MASTER_HOST=‘master_host_ip’,
MASTAR_USER='repl',
MASTER_PASSWPRD='Password',
MASTER_LOG_FILE='mysql_log_file_name',
MASTER_LOG_POS=4;

优点：
是Mysql是最早支持的复制技术，Bug相对较少
对SQL查询没有任何限制
故障处理比较容易

缺点：
故障转移时重新获取新主的日志点信息比较困难

基于GTID的复制
全集事务id
GTID=SOURCE_ID:TRANSACTION_ID
在主DB服务器上建立复制账号：
bin_log=/usr/log/mysql/log、mysql-bin
server_id=100
gtid_mode=on
enforce-gtid-consiste
log-slave-updates=on
-------------create table ...select 在事务中使用create temporary table 建立临时表 使用关联更新事务表和非事务表 会报错

log-slave-updates=on

配置从数据库服务器read_only=on[建议]
master_info_repository=TABLE[建议]
relay_log_info_repository=TABLE[建议]

启动
CHANGE MASTER TO MASTER_HOST=‘master_host_ip’,
MASTAR_USER='repl',
MASTER_PASSWPRD='Password',
MASTER_AUTO+POSITION=1

优点：
可以很方便的进行故障转移
从库不会丢失主库上的任何修改

缺点:
故障处理比较复杂
对执行的sql有一定的限制

选择MYSQL复制模式
所使用的mysql版本
复制架构及主从切换的方式
所使用的高可用管理组件
对应用的支持程度

一主多从拓扑
优点:配置简单
可以用多个从库分担读负载
用途：
为不同业务使用不同的从库
将一台从库放到远程IDC，用作灾备份恢复
分担主库的读负载

主-主复制拓扑
主主模式的主主复制

主主模式下的主-主复制的配置注意事项
产生数据冲突而造成复制链路的中断
耗费大量时间
数据丢失

注意事项:
二哥主中所操作的表最好能够分开
使用下面二哥参数控制自增ID的生成
    auto_increment_increment=2
    auto_increment_offset=1|2

主备模式下的主-主复制的配置注意事项
只有一台主服务器对外提供服务
一台服务器处于只能状态并且只作为热备使用
在对外提供服务的主库出现故障或是计划性的维护时才会进行切换
使原来的备库成为主库，而原来的主库成为新的备库并处理制度厚实下线状态，带维护完成后重新上线。

注意事项
确保两台服务器上的初始数据相同
确保两台服务器上已经启动binlog并且不同的srver_id
在两台服务器上汽的log_slave_updates参数
才初始的备库启动read_only

级联复制--分发主库 slave_log_update;

主从延迟问题：
主库写入二进制日志时间
控制主库的事务大小，分隔大事务
二进制日志传输时间
二进制大小

默认情况下只有一个sql线程，主上并发的修改在从上变成了串行=》使用多线程复制
在MySQL5.7中可以按照逻辑时钟的方式来分配SQL线程
stop slave set global slave_parallel_type='logical_clock'
set global slave_paraller_workers=4;
start slave;

mysql复制常见问题处理
由于数据损毁都丢失所引起的主从复制错误
主库或者从库宕机引起的错误
    使用跳过二进制日志事件
    注入空事务的方式先回复中断的复制链路
    在使用其他方法来对比主从服务器上的数据
主库上的二进制日志损坏
    通过changs master命令来重新指定
备库上的中继日志损坏
在从库上进心数据修改造成的主从复制错误
不唯一的server_id货server_uuid
max_allow_packet设置引起的主从复制错误

无法解决
分担主数据库的写负载
自动进行故障转移及主从切换
提供读写分离功能

MMM监控MySQL主从复制健康情况

MMM部署步骤
1.配置主主复制及主从同步集群
2.安装主从节点多需要的支持包
3.安装及配置MMM工具集
4.运行MMM监控服务
5.测试

enabled=1  baseurl注释
chang

MHA架构
提供什么功能:
监控主数据库服务武器是否可用
当主DB不可用时，从多个从服务器中选举出新的主数据库服务器
提供了主从切换和故障转移功能

MHA主从切换过程
尝试从出现故障的主数据库保存二进制日志
从多个备选从服务器中选举出新的备选主服务器
在备选主服务器和其他从服务器之间差异二进制数据

应用从原主DB服务器保存的二进制日志
MHA支持GTID的复制 SSH免认证登录
每个服务器安装MHA-node软件包和MHA-manager软件包--主服务器安装

支持日致点和GTID的复制
使用masterha_check_ssh(免认证进行认证)和masterha_check_repl对配置进行检查
启动并测试MHA服务

MHA有点和不足:Perl语言
可以基于GTID复制模式
MHA在进行故障转移时更不易产生数据丢失
同一个监控节点可以监控多个集群

缺点虚拟VIP的配置
MHA启动后只会对主数据库进行监控
需要基于SSH免认证配置，存在一定安全隐患
没有提供从服务器的读负载均衡功能

读写分离和负载均衡
读写分离
程序实现读写分离--优点
    有开发人员控制什么样查询在从库中执行，因此比较灵活
    由程序直接连接数据库，所以性能损耗比较少
缺点: dba
    增加开发的工作量，使程序代码更加复杂
    人为控制，容易出现错误
中间件实现读写分离 mysql-proxy  maxScale
maxScale
中间件优缺点:
由中间件根据查询语法分析，自动完成读写分离
对程序透明，对已有程序不用做任何调整
缺点：
增加中间层，所以对查询效率有损耗
对于延迟敏感业务无法自动在主库执行

负载均衡
lvs 
HAaproxy
MaxScale