十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
下文内容主要给大家带来Mysql复制定义及解析,这里所讲到的知识,与书籍略有不同,都是创新互联专业技术人员在与用户接触过程中,总结出来的,具有一定的经验分享价值,希望给广大读者带来帮助。
Master/Slave
Master: write/read,写操作都在主节点上操作
Slaves: read,读操作都是从节点这边发出
为什么要复制?
冗余:promte(提升为主),异地灾备,可以通过人工或者工具程序(MHA)实现
扩展:转移一部分“读”请求;
支援安全的备份操作;
测试需要;
主/从架构实现:
在主节点上启用二进制日志,从节点启动连接线程,请求主节点把这个事件发给自己一份,从节点上有一个线程叫IO Thread,主节点上启用dump thread,IO Thread从节点将接受到的日志存储到中继日志,从云服务器上的SQL THread负责从中继日志里生成一份数据。这样的数据同步方式是异步。主服务器负责写操作,从服务器负责读操作。
主从有可能导致主从数据不一致。如主服务多线程进程,从服务区是单线程进程,有可能导致主从数据不一致,从服务器的数据可能会落后于主服务器,这个问题是不可避免的,只能尽早发现,将不正确的数据手动更改,如果数据差别很大,手动恢复很难,可以在主服务器上做备份,把数据直接回复到从服务器上。
主服务器存到二进制log,存到从服务器上是异步操作的。传输是单向的。但是这里有个问题,如果写操作超出主服务器的性能,解决方法,使用双主模型
主从复制的三种形式:同步复制,异步复制,半同步复制
同步复制:
双主模型:写操作都在本地写,同步给另一个节点,放到relay中。
主服务器都要启动中继日志和二进制日志,所有发给本节点的写操作,都要记录到二进制日志中,并通过dump thread发给对端主服务器,对端主服务器通过io thread将收到的数据存储到中继日志中,并依靠sql thread实现重放。主节点实现了冗余。每个节点都可以读和写操作。这种操作可以降低读请求,每个服务器负载一半的请求,但是写操作的请求数量是一样的,因为,双主的服务器都要写入一份数据。
利用中间件的读写分离器实现请求读写分离,中间件可以利用keepalive实现冗余。但是有了双主模型,就不需要读写分离,只需要用haproxy或者nginx或者lvs来实现请求的四层调度将请求调度到不同服务器上即可。
mysql主从复制弊端可能运行一段时间后,根据业务逻辑的不一样,可能导致主从数据不一致,导致得到的数据不一致。该情况在数据要求强一致的情况下是不允许存在的。
在主服务器上,操作是多线程并行的,但是记录到二进制文件中是串行记录,从服务器是单线程运行获取数据,这样导致从服务器拉取数据的速度落后于主服务器,导致了数据的差异,长此以往会导致数据严重不一致。如果这里设置读写分离,可能导致从服务器上读出的数据是错误的。双主模型同样有这个问题。主从数据不一致,建议解决办法是手动修改数据。如果数据差别太大,将从服务器关闭,在主服务器上做备份,恢复到从服务器上。
异步复制:
一主多从;
一从一主;
级联复制;一主复制给一从,同时,这个从服务器又是其他服务器的主,其他从服务器到这个中继服务器复制数据,级联的作用是降低主服务器的压力。中间的这个从服务器要启用二进制日志和中继日志,同时,中间这台从服务器仅起到过渡的作用,不需要保存数据,因此将block hole引擎用于这个中间从服务器上,使得不会产生数据保存,但是中继日志和二进制日志都有正常保存,起到过渡的效果。
循环复制;多主模式下,采用循环复制,但是链条更长,可能导致数据落后严重。
双主复制;
半同步复制:
一从多主模型:每个主服务器提供不同的数据库,master只保证slaves中的一个操作成功,就返回,其他slave不管。这个功能,是由google为MYSQL引入的。
对于以上关于Mysql复制定义及解析,如果大家还有更多需要了解的可以持续关注我们创新互联的行业推新,如需获取专业解答,可在官网联系售前售后的,希望该文章可给大家带来一定的知识更新。
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。