mysql体系架构和主从复制
MYSQL的发展背景和特性；
MYSQL的体系架构组成；
MYSQL的各种存储引擎及适用场景；
MYSQL主从复制的基本原理；
MYSQL常见的主从复制架构和高可用架构；
总结处理复制延迟和复制不一致的问题。
版本介绍：
Mysql GA(ORACLE)
Percon mysql
MariaDB
开源
开放源代码且无版权制约，自主性强、使用成本低可根据
历史悠久、社区及用户非常活跃，遇到问题，可以很快获取到帮助。
可移植：
支持多种操作系统，提供多种api几口，支持多种开发语言。
安全：
有着非常完善的用户和权限系统，当你建立连接时，可以通过加密的方式来保证他通信安全。
Mysql的体系架构：
常用的存储引擎和特性对比
MYSQL从5.5.5版本开始默认存储引擎为InnoDB（表级别)
基本概念
MYSQL从3.2.3版本开始提供复制的功能，复制是指将主库的DDL和DML（除select）操作通过二进制日志传到服务器上（从库），然后再从库上对这些日志重新执行（也叫重做），从而使得从库和主库的数据保持同步。
为什么要做主从复制：
z
辅助备份
分担负载
应用场景
应用场景1：从服务器作为主服务器的实时数据备份
应用场景2：主从服务器实现读写分离，服务器实现负载均衡
应用场景3：把多个从服务器根据业务重要性进行拆分访问
复制的原理
Master：binlog dump 线程。Slave: I/O线程,Slave: SQL线程
异步复制
主节点只需要把写入操作在本地完成，就响应用户。
半同步复制&增强半同步复制
为了保证主库上的每一个binlog事务都能够被可靠的复制到从库上，主库在每次事务提交成功时，并不是及时反馈给客户端用户，而是等待其中一个从库也接收到了binlog并成功将事务记录到了中继日志中，然后才反馈给用户。
rpl_semi_sync_master_timeout
set globalrpl_semi_sync_master_wait_point=AFTER_COMMIT;
半同步复制的配置：
半同步参数需要先注释掉，等初始化完成之后安装好半同步插件，再开启半同步参数
如果是双主架构则主备库都需要安装：
rpl_semi_sync_master_enabled= 1
rpl_semi_sync_slave_enabled= 1
maser
slave
结果：
完全同步的复制
当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
一主一从
主主复制
一主多从---扩展系统读取的性能，因为读是在从库读取的；
多主一从---5.7开始支持
联级复制
MYSQL的主从复制-高可用架构对比
| 分类 |
MM |
MHA |
MGR |
| 优势 |
主主模式能将读写请求分摊到两个主节点，有效提升服务器使用率。 |
MHA除了支持日志点的复制还支持GTID的方式 |
基本无延迟，延迟比异步的小很多 |
| 主节点发生故障后，能快速进行主从切换。 |
同MMM相比，MHA会尝试从旧的Master中恢复旧的二进制日志，只是未必每次都能成功。如果希望更少的数据丢失场景，建议使用MHA架构。 |
支持多写模式，但是目前还不是很成熟 |
|
| 当故障节点恢复后，故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。 |
数据的强一致性，可以保证数据事务不丢失 |
||
| 不足 |
当主节点上MySQL实例发生故障后，可能会存在部分数据(Binlog)未同步到另外的主节点，导致数据丢失(直到故障节点恢复)。 |
MHA需要自行开发VIP转移脚本。 |
仅支持innodb |
| 主主模式下，很容易因数据访问控制不当导致数据冲突。 |
MHA只监控Master的状态，未监控Slave的状态 |
只能用在GTID模式下，且日志格式为row格式 |
|
| 为提高系统高可用性，双主架构会被扩展成双主多从结构，同样存在主节点发生故障后多个从库选主和恢复复制的问题。 |
|||
| 适用场景 |
读写都需要高可用的场景 |
一主多从的环境下，MySQL的主从复制是异步或是半同步。 |
对主从延迟比较敏感 |
| 希望对对写服务提供高可用，又不想安装第三方软件 |
|||
| 数据强一致的场景 |
如何处理同步延迟
1. 如果是机械盘：
set globalinnodb_flush_neighbors=2;
表示刷新在buffer pool 中位于磁盘上相同的extend 区的脏页，通过AIO可以将多个IO写入操作合并为一个IO操作，增大写入量，减少了物理写IO。
2.如果是IO的问题：
set globalinnodb_io_capacity=1200; （默认200）
即每秒的输入输出量（或读写次数）。
3.临时调整：
set globalinnodb_flush_log_at_trx_commit=2; (默认为1)
set globalsync_binlog=0;
同步之后需要调整回：
set globalinnodb_flush_log_at_trx_commit=1;
set globalsync_binlog=1;
错误信息
错误分析
mysqlbinlogmysql-bin.xxx -vv --base64-output=decode-rows --start-position=a--stop-position=b>/tmp/test.log
错误分析结论
200711 8.49 –9：42期间日志中断，原因是这段时间内，主机重启了，而二进制这部分日志传输到备库的时候丢失了。
解决方案
主库：
确定备库丢失的二进制日志的内容（根据时间或者位点信息）
经过排查确定丢失的日志为mysql-bin000333中的start-position=362945607 到 stop-position=363101485的内容。
备库：中端将
mysqlbinlog--skip-gtids --start-position=362945607 --stop-position=363101485mysql-bin000333 |mysql -utest -p -h ip