前言
先来谈谈Mysql集群的可行方案
MySQL Cluster
由Mysql本身提供，优势：可用性非常高，性能非常好。每份数据至少可在不同主机 存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不 适合比较核心的线上系统，所以不推荐。
DRBD磁盘网络镜像方案
Distributed Replicated Block Device，其实现方式是通过网络来镜像整个设备(磁盘). 它允许用户在远程机器上建立一个本地块设备的实时镜像,与心跳链接结合使用, 也可看做一种网络RAID。
优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可 靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求 。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无 法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL 高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。
MySQL Replication
今天的主题，在实际应用场景中，MySQL Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过 Replication功能提升系统的扩展性后，通过简单的增加价格低廉的硬件设备成倍 甚至成数量级地提高了原有系统的性能。
主从复制原理概述
( 1 )首先, MySQL主库在事务提交时会把数据变更作为事件 Events 记录在二进制日志文件Binlog中; MySQL主库上的 sync_binlog参数控制 Binlog日志刷新到磁盘。
( 2 )主库推送二进制日志文件 Binlog中的事件到从库的中继日志 Relay Log, 之后从库根据中继日志 Relay Log重做数据变更操作, 通过逻辑复制以此来达到主库和从库的数据一致。
3个线程
MySQL通过3个线程来完成主从库间的数据复制:
Binlog Dump线程跑在主库上
I/O线程和 SQL线程跑在从库上
当在从库上启动复制时,首先创建I/O程连接主库, 主库随后创建 Binlog Dump线程读取数据库事件并发送给 I/O线程, IO线程获取到事件数据后更新到从库的中继日志 Relay Log中去,之后从库上的 SQL线程读取中继日志RelayLog中更新的数据库事件并应用。
SHOW PROCESSLIST命令
通过 SHOW PROCESSLIST命令在主库上查看BinlogDump线程
从 BinlogDump 线程的状态可以看到, Mysql的复制是主库主动推送日志到从库去的,是属于“推”日志的方式来做同步。
通过 SHOW PROCESSLIST可以在从库上查看l/O线程和 SQL线程
l/O线程(Id=5)等待主库上的 Binlog Dump线程发送事件并更新到中继日志 RelayLog
SQL线程(Id=6)读取中继日志并应用变更到数据库
二进制日志文件 Binlog三种格式(复制方式)
Statement:基于 SQL语句级别的 Binlog,每条修改数据的 SQL都会保存到 Binlog里。
Row:基于行级别,记录每一行数据的变化,也就是将每行数据的变化都记录到 Binlog 里面, 记录得非常详细, 但是并不记录原始 SQL; 在复制的时候, 并不会因为存储过程或触发器造成主从库数据不一致的问通, 但是记录的日志量较 Statement格式要大得多 。
Mixed:混合Statement和Row模式,默认情况下采用 Statement模式记录, 某些情况下会切换到 Row模式 同时也对应了 MysQL复制的3种技术。
查看当前复制方式
show variables like '%binlog%format%';
更改复制方式
set global binlog_format = 'ROW';
set global binlog_format = 'STATEMENT';
