mysql 架构 主从_mysql体系架构和主从复制

主要内容

MYSQL的发展背景和特性；

MYSQL的体系架构组成；

MYSQL的各种存储引擎及适用场景；

MYSQL主从复制的基本原理；

MYSQL常见的主从复制架构和高可用架构；

总结处理复制延迟和复制不一致的问题。

MYSQL的体系结构介绍

版本介绍：

Mysql GA(ORACLE)

Percon mysql

MariaDB

开源

开放源代码且无版权制约，自主性强、使用成本低可根据

历史悠久、社区及用户非常活跃，遇到问题，可以很快获取到帮助。

可移植：

支持多种操作系统，提供多种api几口，支持多种开发语言。

安全：

有着非常完善的用户和权限系统，当你建立连接时，可以通过加密的方式来保证他通信安全。

Mysql的体系架构：

常用的存储引擎和特性对比

MYSQL从5.5.5版本开始默认存储引擎为InnoDB(表级别)

MYSQL的主从复制

基本概念

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;

MYSQL的主从复制-处理主从不同步的案例

错误信息

错误分析

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