MySQL集群部署简介

异步复制

主从复制的作用

• 是确保数据安全；做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据的丢失。
• 是提升I/O性能；随着日常生产中业务量越来越大,I/O访问频率越来越高，单机无法满足，此时做多库的存储，有效降低磁盘I/O访问的频率，提高了单个设备的I/O性能。
• 是读写分离，使数据库能支持更大的并发；在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

基于position的主从复制

异步复制（主从复制）master节点不会关心slave节点的状态，只需要写自己的数据即可
能不能完成复制看slave节点的io线程和sql线程是否开启

主从复制的要求：

（1）主库开启binlog日志（设置log-bin参数）
（2）主从server-id不同
（3）从库服务器能连同主库

主从复制的原理：

mysql的主从配置又叫replication，AB复制，基于binlog二进制日志，主数据库必须开启binlog二进制日志才能进行复制

（1） master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
（2）从库生成两个线程，一个i/o线程，一个SQL线程，i/o线程去请求主库的binlog，sql线程进行日志回放来复制
（3） slave将master的binary log events拷贝到它的中继日志(relay log)；
（4）slave重做中继日志中的事件，将更改应用到自己的数据上。

mysql的主从复制（异步复制）（基于position）把一个事件拆开来复制，并不是以一个完整的事件为单位来进行复制

异步复制：在主节点写入日志即返回成功，默认情况下MySQL5.5/5.6/5.7和mariaDB10.0/10.1的复制功能是异步的
异步复制可以实现最佳的性能，主库把binlog日志发送给从库，这一动作就结束了，并不验证从库，会造成主从库数据不一致

1.从数据库执行change master to 命令(主数据库的连接信息+复制的起点)
2.从数据库会将以上信息,记录到master.info文件
3.从数据库执行 start slave 命令,立即开启SLAVE_IO_THREAD 和SLAVE_SQL_THREAD这两个线程
4.从数据库 SLAVE_SQL_THREAD,读取master.info文件中的信息获取到IP,PORT,User,Pass,binlog的位置信息
5.从数据库SLAVE_IO_THREAD请求连接主数据库,主数据库专门提供一个SLAVE_IO_THREAD,负责和SLAVE_SQL_THREAD交互
6.SLAVE_IO_THREAD根据binlog的位置信息,请求主数据库新的binlog
7.主数据库通过Binlog_DUMP_Thread将最新的binlog,通过网络TP给从数据库的SALVE_IO_THREAD
8.SLAVE_IO_THREAD接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
9.SLAVE_IO_THREAD将TCP/IP缓存中数据,转储到磁盘relaylog中.
10.SLAVE_SQL_THREAD读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
11.SLAVE_SQL_THREAD会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
12.从数据库会自动purge应用过relay进行定期清理，一旦主从复制构建成功,主数据库当中发生了新的变化,都会通过 slave_dump_THREAD发送信号给SLAVE_IO_THREAD,增强了主从复制的实时性.

(1) 在Slave 服务器上执行sart slave命令开启主从复制开关，开始进行主从复制。

(2) 此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从执行binlog日志文件的指定位置(日志文件名和位置就是在配置主从复制服务时执行change master命令指定的)之后开始发送binlog日志内容

(3) Master服务器接收到来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外，还有在Master服务器端记录的IO线程。返回的信息中除了binlog中的下一个指定更新位置。

(4) 当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log(即中继日志)文件(Mysql-relay-bin.xxx)的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容

(5) Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容，然后及时把Relay LOG 文件中的内容解析成sql语句，并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句，并在relay-log.info中记录当前应用中继日志的文件名和位置点

基于gtid的主从复制

GTID复制不像传统的复制方式（异步复制、半同步复制）需要找到binlog（MASTER_LOG_FILE）和POS点（MASTER_LOG_POS），只需要知道master的IP、端口、账号、密码即可，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步，和基于position的主从复制的不同之处在于：它是以一整个事件为单位进行复制的GTID复制

名词释义

server-id：服务器身份id，在初始化MySQL时，会自动生成一个server-id并写到数据目录的auto.cnf文件中，官方不建议修改，并且server-id跟GTID有密切关系，并且对于任意一个数据库节点，server-id是唯一的
GTID：全局事务标识符，使用这个功能时，内次事务提交都会在binlog里生成一个唯一的标识符，它由UUID和事务ID组成，首次提交的事务为1，第二次为2，第三次为3，以此类推。

GTID工作流程

• 在master上一个事务提交，并写入binlog里。
  binlog日志发送到slave，slave接收并写入中继日志里，slave读取到这个GTID，并设置gtid_next的值。
• 然后告诉slave接下来的事务必须使用GTID，并写入它自己的binlog里。
• slave检查并确认这个GTID没有被使用，如果没有被使用，那么开始执行这个事务并写入自己的binlog里
• 由于gtid_next的值不为空，slave不会尝试去生成一个新的gtid而是通过主从同步来获取GTID
• 下来实现基于gtid的主从复制（以一个事件为单位进行复制）
  异步复制的效率高，master节点不会等待slave节点
  基于gtid的主从复制不容易因为master一个事件的中断而造成数据丢失而不能复制
  基于position的主从复制容易因为master一个事件的中断而造成数据丢失而不能复制

GTID即全局事务ID (global transaction identifier),其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。

GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid)产生于auto.conf文件(cat/data/mysql/data/auto.cnf)，是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。
GTID在一组复制中，全局唯一。通过GDIT保证每个主库上提交的事务在集群中有一个唯一的ID.这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

主从复制,默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号,我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术。

pos和GTID都是日志文件里事件的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,GTID就是全局的主从库都编辑配置文件，重启mysqld服务 由于同一事务的GTID在所有节点上的值一致 我们都不需要知道GTID的具体值。需要做好前面的binlog复制。
在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。

从服务器连接到主服务器之后，把自己执行过的GTID(Executed_Gtid_Set)<SQL线程>获取到的GTID(Retrieved_Gtid_Set）<IO线程>发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先change到同步最成功的那台从服务器， 等把GTID全部补全了，就可以把它提升为主了

半同步复制

半同步复制的由来

在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。于是在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中

1）正常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

2）异常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

3）很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。

参数说明

rpl_semi_sync_master_enabled = 1	表示在master上已经开启了半同步复制模式；
rpl_semi_sync_master_timeout = 10000	表示如果主库在某次事务中的等待时间超过10000毫秒，则降级为异步复制模式，不在等待slave从库。如果主库再次探测到slave从恢复了，则会自动切换回半同步复制模式；
rpl_semi_sync_master_wait_no_slave	表示是否允许master每个事务提交后都要等待slave的接收确认信号。默认为ON，即每一个事务都会等待。如果为OFF，则slave追赶上之后，也不会开启半同步复制模式，需要手工开启；
rpl_semi_sync_master_trace_level = 32	指用于开启半同步复制模式时的调试级别，默认为32。可以看出，在配置Master的时候，只设置了1，其他的都采取的默认设置。

全同步复制

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。

读写分离

1.mysql数据库的读写分离的基础知识（为什么要进行读写分离）
对于很多大型网站（pv值百万、千万）来说，在所处理的业务中，其中有70%的业务是查询（select）相关的业务操作
（新闻网站，插入一条新闻，查询操作）
剩下的则是写（insert、update、delete，只要能对MySQL的数据造成更改的操作都叫写操作）操作
在使用负载均衡集群之后，可以很大程度的提升网站的整体性能，但是最终的数据处理的压力还是会落到MySQL数据库上
所有很有必要使用一些技术来提升MySQL的负载能力。（读写分离）
写专门交给写服务器处理（一般网站来说写是比较少的 读写比 4:1） 那么需要把读的任务分配多台服务器来完成的架构，就叫做读写分离

2.读写分离的实现方式
（1）php程序上自己做逻辑判断，写php代码的时候，自己在程序上做逻辑判读写匹配。select，insert、update、delete做正则匹配，根据结果选择写服务器（主服务器）。如果是select操作则选择读服务器（从服务器器） mysql_connect(‘读写的区分’)

（2）MySQL- Proxy是实现"读写分离(Read/Write Splitting)"的一个软件（MySQL官方提供 ，也叫中间件），基本的原理是让主数据库处理写操作（insert、update、delete），而从数据库处理查询操作（select）。而数据库的一致性则通过主从复制来实现。所以说主从复制是读写分离的基础。

注意：MySQL-proxy 它能实现读写语句的区分主要依靠的是内部一个lua脚本（能实现读写语句的判断）
注意：如果只在主服务器（写服务器）上完成数据的写操作话；这个时候从服务器上没有执行写操作，是没有数据的
这个时候需要使用另外一个技术来实现主从服务器的数据一致性，这个技术叫做 主从复制技术， 所以说主从复制是读写分离的基础
读写分离(MySQL- Proxy)是指让master处理写操作，让slave处理读操作，非常适用于读操作量比较大的场景，可减轻master的压力
使用mysql-proxy实现mysql的读写分离，mysql-proxy实际上是作为后端mysql主从服务器的代理，它直接接受客户端的请求
对SQL语句进行分析，判断出是读操作还是写操作，然后分发至对应的mysql服务器上
因为数据库的写操作相对读操作是比较耗时的，所以数据库的读写分离，解决的是数据库的写入，影响了查询的效率

数据库高可用

MMM高可用方案

Mysql-MMM介绍

MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。

组件

mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。此脚本需要在监管机上运行。
mmm_agentd：运行在每个mysql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
mmm_control：一个简单的脚本，提供管理mmm_mond进程的命令。
mysql-mmm的监管端会提供多个虚拟IP（VIP），包括一个可写VIP，多个可读VIP，通过监管的管理，这些IP会绑定在可用mysql之上，当某一台mysql宕机时，监管会将VIP迁移至其他mysql。
在整个监管过程中，需要在mysql中添加相关授权用户，以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户，如果想使用mmm的备份工具则还要添加一个mmm_tools用户。

架构图
正常工作时：

主节点故障时：

MMM优点

（1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。

（2）配置简单，容易操作。

MMM缺点

（1）需要一台备份服务器，浪费资源

（2）需要多个虚拟IP

（3）agent可能意外终止，引起裂脑。

MHA介绍

MHA（Master High
Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA架构介绍

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失(配合mysql半同步复制效果更佳)，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

注意：目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

MHA架构图
正常工作时架构图：

主库down机时架构：

故障转移过程

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

（7）在新的master启动vip地址，保证前端请求可以发送到新的master。

MHA优点

（1）不需要备份服务器

（2）不改变现有环境

（3）操作非常简单

（4）可以进行日志的差异修复

（5）可以将任意slave提升为master

MHA缺点

（1）需要全部节点做ssh秘钥

（2）MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。

（3）自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。

DRBD+（heartbeat,corosync）

方案简介

本方案采用Heartbeat或者corosync双机热备软件来保证数据库的高稳定性和连续性，数据的一致性由DRBD这个工具来保证（如果可以尽量放到分布式存储上面）。默认情况下只有一台mysql在工作，当主mysql服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主mysql提供服务。

组件

Heartbeat,corosync作为心跳检测机制，监控primary节点的状态。当主节点宕掉之后，迅速提升secondary节点为新的主节点，并切换IP；

drbd负责数据同步

架构图

数据同步过程

mysql进行刷盘时，会通过不同的sync方式，最终将数据写入disk；

drbd收到刷盘成功的信息后，将对应的磁盘块位置，和变更动作，通过网络传递至secondary节点；

secondary的drbd接收到变更信息后，将这些信息落盘；

切换过程

前提：secondary节点的mysql服务不启动；

heartbeat检测到primary的mysql服务停止，则摘掉IP、umount掉数据盘、将primary切换为secondary；

在原来的secondary上，提升drbd同步为primary，挂载数据盘，启动mysql服务、绑定IP；

从库跟着IP和端口自动进行迁移；

方案优点

（1）历史悠久、安全性高、稳定性高、可用性高、出现故障自动切换。

（2）数据一致性强

方案缺点

（1）需要一台备份服务器，浪费资源

（2）不方便扩展

（3）无论drbd还是headbetart，corosync都可能发生裂脑

Mysql route介绍

什么是mysql route

MySQL Router是处于应用client和dbserver之间的轻量级代理程序，它能检测，分析和转发查询到后端数据库实例，并把结果返回给client。是mysql-proxy的一个替代品。其架构图和功能如下。
（1）Router实现读写分离，程序不是直接连接数据库IP，而是固定连接到mysql router。MySQL Router对前端应用是透明的。应用程序把MySQL Router当作是普通的mysql实例，把查询发给MySQL Router,而MySQL Router会把查询结果返回给前端的应用程序。

（2）从数据库服务器故障，业务可以正常运行。由MySQL Router来进行自动下线不可用服务器。程序配置不需要任何修改。

（3）主数据库故障，由MySQL Router来决定主从自动切换，业务可以正常访问。程序配置不需要做任何修改。

读写分离原理

MySQL
Router接受前端应用程序请求后，根据不同的端口来区分读写，把连接读写端口的所有查询发往主库，把连接只读端口的select查询以轮询方式发往多个从库，从而实现读写分离的目的。读写返回的结果会交给MySQL
Router,由MySQL Router返回给客户端的应用程序。

Mysql router用途

MySQL Router的主要用途是读写分离，主主故障自动切换，负载均衡，连接池等。

Mysql router主主故障自动切换的坑

Mysql
router主主故障切换功能经过测试没有问题，但是有一个比较大的坑需要注意，主库发生切换之后，从库的连接的master服务器地址不会发生改变，需要自己写脚本进行判断。

5.5.优点

（1）基于DAL层实现mysql的高可用。

（2）可以同时实现主主故障切换和读写分离。

（3）插件式架构允许用户进行额外的功能扩展。

5.6.缺点

（1）高可用功能需要进一步完善：存在主库切换之后，从库不会自动切换主库地址的坑。

（2）读写情况使用不同端口，需要修改应用程序。

不同复制方式的比较

异步复制（Asynchronous replication）	MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
全同步复制（Fully synchronous replication）	指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
半同步复制（Semisynchronous replication）	介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。