MySQL主从库的同步 我们设置一个主库(Master),和一个从库(Slave或Secondary)。从库从主库复制数据内容,目的为灾难备份、读写分离等。 本文主要讲同步机制,至于如何设置MySQL的主库、从库及同步,网上内容很多了,看官只要Google一下“MySQL 主从库 设置”
我们设置一个主库(Master),和一个从库(Slave或Secondary)。从库从主库复制数据内容,目的为灾难备份、读写分离等。
本文主要讲同步机制,至于如何设置MySQL的主库、从库及同步,网上内容很多了,看官只要Google一下“MySQL 主从库 设置”就有了。这里略了。
主库开启binary log,开启后每一次操作更新、修改、删除等都会记录在案,所以从库的同步过程其实就是获得这些过程,然后将现场还原,就达到了数据同步的目的。
为什么讲旧的同步的实现,因为按着开发过程,旧的实现其实就是一个最简原理的表现,虽然考虑不全,都大体方向是对的,所以讲旧的是为了讲新的。
OK,任务完成了,确实是完成了,只是Slave的线程做的事情有点多,既要请求binlog,又要执行,于是Slave和Master的延时其实是蛮大的,也因为这个蛮大的延时,使得假如在这个延时其间如果Master大量变化后崩溃了,而这些binlogs没来得及同步到Slave,这些变化数据就找不回来了。所以,MySQL开发团队认识到这个问题后,就进行一个改进。
原理还是跟旧同步机制一样,只是做了一个改进。这个改进大部分做线程开发的人都懂,把Slave的线程分成两个线程,一个做binlogs的同步(我们称为IO线程),一个做还原现场的工作(我们称为SQL线程)。如此,Master端的binlogs能以最小的延时,同步到Slave,而Slave这边的现场还原工作就可以慢慢来了,反正binlogs是源材料,即使Master崩溃也丢了binlogs,也可以从Slave里取回去还原。
就是这么简单,理解这个实现机制有什么好处?就是方便理解配置MySQL的主库和从库的时候一些配置项以及对MySQL的同步出现问题的时候,知道该往哪个方向去找答案。
但是,不得不说一下,然后新机制貌似解决了同步问题,但是实际上没有,延时还是存在的,只是小了非常多,想想都知道,Slave的IO线程在两次请求之间是有时间距离的,所以这个时间距离内,Master还是有可能变化后崩溃而丢失那部分变化。
所以,事实上要完全避免这个问题,只能用MySQL Cluster(数据库集群)。这是一个大的问题,我们另辟章节来讲。
( 完 )
版权所有:老白经 转载请保留来源信息。 >
已抢66291个
抢已抢36096个
抢已抢20006个
抢