1)MySQL复制允许将主实例(master)上的数据同步到一个或多个从实例(slave)上,默认情况下复制是异步进行的,从库也不需要一直连接到主库来同步数据
2)MySQL复制的数据粒度可以是主实例上所有的数据库,也可以是指定的一个或多个数据库,也可以是一个数据库里的指定的表
1)扩展能力:通过复制功能可以将MySQL的性能压力分担到一个或多个slave上。这要求所有的写操作和修改操作都必须在Master上完成,而读操作可以被分配到一个或多个slave上。将读写分离到不同服务器执行之后,MySQL的读写性能得到提升
2)数据库备份:由于从实例是同步主实例的数据,所以可以将备份作业部署到从库
3)数据分析和报表:同样,一些数据分析和报表的实现可以在从实例执行,以减少对主库的性能影响
4)容灾能力:可以在物理距离较远的另一个数据中心建立一个slave,保证在主实例所在地区遭遇灾难时,在另一个数据中心能快速恢复
1)传统方式:基于主库的bin-log将日志事件和事件位置复制到从库,从库再加以应用来达到主从同步的目的
2)Gtid方式:global transaction identifiers是基于事务来复制数据,因此也就不依赖日志文件,同时又能更好的保证主从库数据一致性
1)异步复制:一个主库,一个或多个从库,数据异步同步到从库
2)同步复制:在MySQL Cluster中特有的复制方式
3)半同步复制:在异步复制的基础上,确保任何一个主库上的事务在提交之前至少有一个从库已经收到该事务并日志记录下来
4)延迟复制:在异步复制的基础上,人为设定主库和从库的数据同步延迟时间,即保证数据延迟至少是这个参数
复制的工作原理是数据库修改事件记录到bin log中并传递到slave,然后slave在本地还原的过程。而事件记录到bin log的格式会有所不同。
1)基于语句的复制(statement based replication):基于主库将SQL语句写入到bin log中完成复制
2)基于行数据的复制(row based replication):基于主库将每一个行数据变化的信息作为事件写入到bin log中完成日志
3)混合复制(mixed based replication):上述两者的结合。默认情况下优先使用基于语句的复制,只有当部分语句如果基于语句复制不安全的情况下才会自动切换为基于行数据的复制
1)基于binary log的复制是指主库将修改操作写入到bin log中,从库负责读取主库的bin log,并在本地复制一份,然后将里面的操作在从库执行一遍
2)每个从库会保存目前读取主库日志的文件名和日志位置
3)主库和每个从库都必须有一个唯一ID,叫server-id配置在配置文件中
1)两台以上mysql实例
2)主库开启二进制日志
3)专用的复制用户
4)保证主从开启之前的某个时间点,从库数据是和主库一致(主库全备导入到从库)
5)告知从库,复制用户信息,IP port,以及复制起点(change master to)
6)线程(三个):
文字说明:
1. Slave 节点,通过IO线程,读取master.info 的信息(IP port user,passwd,file+position ) 2. IO Thread 通过连接信息,连接上主库,主库会生成DUMP THREAD 3. IO 通过 master.info 提供的 file+position,找主库请求比这个新的二进制日志事件 4. Master DUMP thread 截取全新的二进制日志"事件",按照事件为单元,串行传送给 SLAVE IO THREAD 5. SLAVE IO THREAD收到发过来的二进制日志事件,缓存到 TCP/IP cache中,立即返回ACK 给MASTER. 6. SLAVE IO线程,更新master.info中二进制日志信息(已经获取过的二进制日志信息),并且会将TCP/IP缓存 数据写入relay-log日志中 7. SLAVE SQL 线程,读取relay-log.info ,获取到上次已经执行过的relaylog 位置号 8. SQL 线程根据relaylog历史记录,往后继续(串行)执行relaylog,执行完成后,再次更新relay-log.info信息 9. relay-log被应用完成后,会定时自动清理
原文:https://www.cnblogs.com/hujinzhong/p/11649609.html