1、master配置
（1）开启binlog；
（2）创建复制账号：创建账号；授权；刷新权限；
（3）在 Master 的数据库执行 show master status，查看主服务器二进制日志状态及位置号：
2、slave配置
（1）打开中继日志（ relay log）；
（2）设置同步的数据库；
（3）启动slave的同步master的线程；
（4）可使用SHOW SLAVE STATUS\G; 命令查看从服务器状态：
Slave_IO_Running: Yes //IO线程正常运行 Slave_SQL_Running: Yes //SQL线程正常运行
（1）master执行了写操作后会写入到 binlog 中，通知 dump 线程去推送更新的 binlog 到 slave；
（2）slave 接收到数据之后通过 I/O 线程写入到 relay log中；
（3）slave 的 SQL 线程会从 relay log 中读取数据并执行写入到DB中；
1、主从复制的方式
（1）同步复制
当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。需要有超时时间。
（2）异步复制
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返回给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
（3）半同步方式
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
注意：Master在给 Slave 推送了一个数据之后，默认10s之后Slave 还未给 Master 一个 ACK，则半同步方式会给降级，变为异步同步的方式。
三、高可用架构方案
1、MMM高可用方案（已经淘汰）
MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)
优点
（1）高可用性，扩展性好，出现故障自动转移，对于主主同步，在同一时间只提供一台数据库写操作，保证数据的一致性。
（2）配置简单，容易操作。
缺点
（1）需要一台备份服务器，浪费资源；
（2）需要多个虚拟IP；
（3）agent可能意外终止，引起裂脑。
若当前的 master1 产生了网络抖动的情况，将会把 master2 切换为 可读可写 的方式，master1 抖动过后也是 可读可写的方式，就产生了脑裂；
2、MHA方案
MHA服务，有两种角色， MHA Manager(管理节点)和 MHA Node(数据节点)。在MySQL故障切换过程中，MHA能做到在 0~30秒 之内自动完成数据库的故障切换操作，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器。
MHA 也可能发生脑裂，但是可以解决；在进行主从切换的时候，选出数据最接近master的slave的作为新的 master，将 slave 切换为 master 之后，允许执行一个 shell 脚本，将原来的 master 服务关掉。
优点
（1）不需要备份服务器；
（2）不改变现有环境；
（3）操作非常简单；
（4）可以进行日志的差异修复；
（5）可以将任意slave提升为master；
缺点
（1）需要全部节点做ssh秘钥；
（2）MHA出现故障后配置文件会被修改，如果再次故障转移需要重新修改配置文件。
（3）自带的脚本还需要进一步补充完善，且用perl开发，二次开发困难。
四、分库分表
1、为什么需要分库分表？
（1）读写分离；
（2）建索引，优化查询；
（3）
2、有哪些拆分方式？
横向拆分
数据量庞大的表，拆分为结果一样的几个表；
纵向拆分
