一、主从复制原理
1、主库db的更新事件(update、insert、delete)被写到binlog（这个log开启的话有时候可以用于恢复误删数据）；
2、从库启动并发起连接到主库，等待主库发送信息；
3、binlog有新写入，主库创建一个binlog dump thread，把binlog的内容发送到从库；
4、从库创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log；
5、从库创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到从库的db。这就相当于根据log进行的一次复盘重现的动作，从而主从数据同步。
二、主从复制的实现
这块基本是配置完配置文件即可实现同步了，直接参考了一篇文章，小马搞过可行但没有亲手做笔记，这里小马就不赘述了。
总结一下：
1、主配置，自定义主服务器ID，开启binlog日志同步功能，定义binlog日志文件名（从库开启同步要用到这个文件名指定从这个文件同步数据）；
2、重启主库，并登陆主库授权给从库服务器用户：grant replication slave on *.* to'mark'@'192.168.1.201'identified by'123456'; ##授权给从数据库服务器192.168.1.201，用户名mark，密码123456；
3、查看主库状态。得到file,position这两个值（从库开启同步要用，指定同步的文件名和开始位置）；
4、从库配置，和第一步一样；
5、重启从库，登录并设置开启同步的参数：change master to master_host='192.168.1.200', master_user='mark' ,master_password='123456', master_log_file='mysql-bin-200.000002' ,master_log_pos=1167;注意到这个是个连接配置，以授权用户连到主库并指定了要找哪个binlog日志文件，以及本次开始同步的log位置。
这种同步方式需要指定master_log_pos位置，这对于如果中间从库down机再次同步要找到同步位置十分麻烦，设置不当会因表的主键插入重复问题会直接影响同步失败，失败后同步后续也将停止。因此我们可以考虑GTID的方式（需配置文件配置），无需指定每次的位置。
GTID概述：
1、全局事物标识：global transaction identifieds。
2、GTID事物是全局唯一性的，且一个事务对应一个GTID。
3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
4、GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。
5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
6、在传统的slave端，binlog是不用开启的，但是在GTID中，slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。
主从搞完了不仅仅是容灾，当然还有用来读写分离了，只要服务器安装了mysql proxy或Ameoba软件就可以实现读写分离和负载均衡。小马认为，可以认为这是服务器实现层面的，也就是中间件自己判断是读还是写自己找到配置的机器，以及自己计算负载自己实现均衡。但在TP框架主从DB配置中似乎主从读写分离的实现是从代码层面实现的，是否有印象呢？
三、RDS和ECS MySQL的同步
你搞过阿里云RDS和ECS MySQL的主从同步吗？小马就搞过，可行。基本上和上面的教程配置方式一样，唯一不同的是RDS可以不用作配置只需要配置从库的就可以了。虽然比较经济，但是不是很推荐，因为会出现主从不能及时同步的情况，只适合做备份；而且从库非常不稳定经常容易挂机。
参考文章：
