MySQL复制经常使用拓扑结构具体解释
(1) 每一个slave仅仅能有一个master;
(2) 每一个slave仅仅能有一个唯一的serverID;
(3) 每一个master能够有非常多slave;
(4) 假设你设置log_slave_updates,slave能够是其他slave的master,从而扩散master的更新。
MySQL不支持多主server复制(Multimaster Replication)——即一个slave能够有多个master。
可是。通过一些简单的组合,我们却能够建立灵活而强大的复制体系结构。
1、单一master和多slave
Slave之间并不相互通信,仅仅能与master进行通信。
在实际应用场景中,MySQL复制90%以上都是一个Master拷贝到一个或者多个Slave的架构模式。主要用于读压力比較大的应用的数据库端便宜扩展解决方式。由于仅仅要Master和Slave的压力不是太大(尤其是Slave端压力)的话,异步复制的延时一般都非常少非常少。尤其是自从Slave端的复制方式改成两个线程处理之后。更是减小了Slave端的延时问题。而带来的效益是,对于数据实时性要求不是特别Critical的应用,仅仅须要通过便宜的pcserver来扩展Slave的数量,将读压力分散到多台Slave的机器上面。就可以通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈。毕竟在大多数数据库应用系统中的读压力还是要比写压力大非常多。
这在非常大程度上攻克了眼下非常多中小型站点的数据库压力瓶颈问题,甚至有些大型站点也在使用类似方案解决数据库瓶颈。
假设写操作较少。而读操作非常时。能够採取这样的结构。你能够将读操作分布到其他的slave。从而减小master的压力。可是,当slave添加到一定数量时,slave对master的负载以及网络带宽都会成为一个严重的问题。
这样的结构尽管简单,可是。它却很灵活,足够满足大多数应用需求。一些建议:
(1) 不同的slave扮演不同的作用(比如使用不同的索引。或者不同的存储引擎)。
(2) 用一个slave作为备用master,仅仅进行复制;
(3) 用一个远程的slave。用于灾难恢复;
大家应该都比較清楚。从一个Master节点能够复制出多个Slave节点。可能有人会想,那一个Slave节点能否够从多个Master节点上面进行复制呢?至少在眼下来看,MySQL是做不到的。以后是否会支持就不清楚了。
MySQL不支持一个Slave节点从多个Master节点来进行复制的架构。主要是为了避免冲突的问题,防止多个数据源之间的数据出现冲突,而造成最后数据的不一致性。只是听说已经有人开发了相关的patch。让MySQL支持一个Slave节点从多个Master结点作为数据源来进行复制,这也正是MySQL开源的性质所带来的优点。
2、主动模式的Master-Master(Master-Master in Active-Active Mode)
可能有些读者朋友会有一个操心,log-slave-updates 选项就是让slave把replication的事件也写进binlog,假设在互为主从的架构下,開始log-slave-updates不就会导致一个事务在两个mysql之间不断循环吗?实际上MySQL自己早就想到了这一点,所以在MySQL的BinaryLog中记录了当前MySQL的server-id,并且这个參数也是我们搭建MySQLReplication的时候必须明白指定,并且Master和Slave的server-id參数值比须要不一致才干使MySQLReplication搭建成功。
一旦有了server-id的值之后,MySQL就非常easy推断某个变更是从哪一个MySQLServer最初产生的,所以就非常easy避免出现循环复制的情况。并且。假设我们不打开记录Slave的BinaryLog的选项(--log-slave-update)的时候。MySQL根本就不会记录复制过程中的变更到BinaryLog中,就更不用操心可能会出现循环复制的情形了。
主动的Master-Master复制有一些特殊的用处。
比如。地理上分布的两个部分都须要自己的可写的数据副本。这样的结构最大的问题就是更新冲突。
如果一个表仅仅有一行(一列)的数据,其值为1,如果两个server分别同一时候运行例如以下语句:
在第一个server上运行:
mysql> UPDATE tbl SET col=col + 1;
在第二个server上运行:
mysql> UPDATE tbl SET col=col * 2;
那么结果是多少呢?一台server是4。还有一个server是3,可是,这并不会产生错误。
实际上,MySQL并不支持其他一些DBMS支持的多主server复制(Multimaster Replication),这是MySQL的复制功能非常大的一个限制(多主server的难点在于解决更新冲突),可是,假设你实在有这样的需求,你能够採用MySQL Cluster,以及将Cluster和Replication结合起来,能够建立强大的高性能的数据库平台。
可是,能够通过其他一些方式来模拟这样的多主server的复制。
3、主动-被动模式的Master-Master(Master-Master in Active-Passive Mode)
它的不同点在于当中一个服务仅仅能进行仅仅读操作。如图:
4、级联复制架构 Master –Slaves - Slaves
在有些应用场景中。可能读写压力区别比較大。读压力特别的大,一个Master可能须要上10台甚至很多其它的Slave才可以支撑注读的压力。
这时候。Master就会比較吃力了,由于只连上来的SlaveIO线程就比較多了,这样写的压力略微大一点的时候,Master端由于复制就会消耗较多的资源,非常easy造成复制的延时。
遇到这样的情况怎样解决呢?这时候我们就能够利用MySQL能够在Slave端记录复制所产生变更的BinaryLog信息的功能,也就是打开—log-slave-update选项。
然后,通过二级(或者是很多其它级别)复制来降低Master端由于复制所带来的压力。
也就是说,我们首先通过少数几台MySQL从Master来进行复制,这几台机器我们姑且称之为第一级Slave集群,然后其它的Slave再从第一级Slave集群来进行复制。从第一级Slave进行复制的Slave,我称之为第二级Slave集群。假设有须要,我们能够继续往下添加很多其它层次的复制。
这样,我们非常easy就控制了每一台MySQL上面所附属Slave的数量。这样的架构我称之为Master-Slaves-Slaves架构
这样的多层级联复制的架构,非常easy就攻克了Master端由于附属Slave太多而成为瓶颈的风险。下图展示了多层级联复制的Replication架构。
当然,假设条件同意。我更倾向于建议大家通过拆分成多个Replication集群来解决
上述瓶颈问题。
毕竟Slave并没有降低写的量,全部Slave实际上仍然还是应用了全部的数据变更操作,没有降低不论什么写IO。相反,Slave越多,整个集群的写IO总量也就会越多,我们没有非常明显的感觉,只不过由于分散到了多台机器上面,所以不是非常easy表现出来。
此外。添加复制的级联层次。同一个变更传到最底层的Slave所须要经过的MySQL也会很多其它,相同可能造成延时较长的风险。
而假设我们通过分拆集群的方式来解决的话,可能就会要好非常多了。当然,分拆集群也须要更复杂的技术和更复杂的应用系统架构。
5、带从server的Master-Master结构(Master-Master with Slaves)
级联复制在一定程度上面确实攻克了Master由于所附属的Slave过多而成为瓶颈的问题,可是他并不能解决人工维护和出现异常须要切换后可能存在又一次搭建Replication的问题。
这样就非常自然的引申出了DualMaster与级联复制结合的Replication架构,我称之为Master-Master-Slaves架构
和Master-Slaves-Slaves架构相比,差别只不过将第一级Slave集群换成了一台单独的Master,作为备用Master。然后再从这个备用的Master进行拷贝到一个Slave集群。
这样的DualMaster与级联复制结合的架构,最大的优点就是既能够避免主Master的写入操作不会受到Slave集群的复制所带来的影响,同一时候主Master须要切换的时候也基本上不会出现重搭Replication的情况。可是,这个架构也有一个弊端,那就是备用的Master有可能成为瓶颈,由于假设后面的Slave集群比較大的话,备用Master可能会由于过多的SlaveIO线程请求而成为瓶颈。
当然,该备用Master不提供不论什么的读服务的时候,瓶颈出现的可能性并非特别高,假设出现瓶颈。也能够在备用Master后面再次进行级联复制,架设多层Slave集群。当然,级联复制的级别越多,Slave集群可能出现的数据延时也会更为明显,所以考虑使用多层级联复制之前,也须要评估数据延时相应用系统的影响。
MySQL复制经常使用拓扑结构具体解释的更多相关文章
- 理解MySQL——复制(Replication)
1.复制概述 1.1.复制解决的问题数据复制技术有以下一些特点:(1) 数据分布(2) 负载平衡(load balancing)(3) 备份(4) 高可用性(high avai ...
- MySQL复制(三) --- 高可用性和复制
实现高可用性的原则很简单: 冗余(Redundancy):如果一个组件出现故障,必须有一个备用组件.这个备用组件可以是standing by的,也可以是当前系统部署中的一部分. 应急计划(Contig ...
- MySQL复制之实践篇
本文主要以"一个主库,两个备库"代表"一个主库,多个备库"的拓扑结构来展示MySQL复制的实践过程. 拓扑结构: 主库创建复制账号: grant replica ...
- MySQL复制之理论篇
一.MySQL复制概述 MySQL支持两种复制方式:基于行的复制和基于语句的复制(逻辑复制).这两种方式都是通过在主库上记录 二进制日志.在备库重放日志的方式来实现异步的数据复制,其工作原理如下图: ...
- 深入MySQL复制(一)
本文非常详细地介绍MySQL复制相关的内容,包括基本概念.复制原理.如何配置不同类型的复制(传统复制)等等.在此文章之后,还有几篇文章分别介绍GTID复制.半同步复制.实现MySQL的动静分离,以及M ...
- 深入MySQL复制(二):基于GTID复制
相比传统的MySQL复制,gtid复制无论是配置还是维护都要轻松的多.本文对gtid复制稍作介绍. MySQL基于GTID复制官方手册:https://dev.mysql.com/doc/refman ...
- 深入MySQL复制(三):半同步复制
1.半同步复制 半同步复制官方手册:https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html 默认情况下,MySQL的复制是异 ...
- 31.Mysql复制
31.Mysql复制复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上,然后在从数据库上对重做日志,从而使从库与主库保持同步.Mysql支持一台主库同时向多台从库复制,从库也可以作为其 ...
- MySQL复制原理-加强版
mysql从3.23开始提供复制功能,复制指将主库的ddl和dml操作通过binlog文件传送到从库上执行,从而保持主库和从库数据同步.mysql支持一台主库同时向多台从库复制,从库同时也可以作为其他 ...
随机推荐
- ES6中的模板字符串---反引号``
在react中,反引号``有特殊的含义. 如MDN中所述,模板字符串(Template literals)允许嵌入表达式,并且支持多行字符串和字符串插补特性.基本语法为以下几种: 其中第一行为最基本用 ...
- lamp+nginx代理+discuz+wordpress+phpmyadmin
实验课题:搭建LAMP,安装Nginx,作为代理,将MySQL安装在单独的机器,apache负责动态,nginx负责静态 实验环境: 1.VMware Workstation 11 2.设备A:MyS ...
- SyBase 百科
ylbtech_database_sybase 1, 百度百科 http://baike.baidu.com/view/118488.htm?fr=aladdin
- 矩阵压缩写法 scipy spark.ml.linalg里都有,CRS,CCS
CRS 表示:Compressed Row Storage CCS 表示:Compressed Column Storage CRS的表示参考: https://blog.csdn.net/buptf ...
- JAVA之接口与抽象类区别
1.概述 一个软件设计的好坏,我想很大程度上取决于它的整体架构,而这个整体架构其实就是你对整个宏观商业业务的抽象框架,当代表业务逻辑的高层抽象层结构 合理时,你底层的具体实现需要考虑的就仅仅是一些算法 ...
- iptables 使用场景
25 Most Frequently Used Linux IPTables Rules Examples by RAMESH NATARAJAN on JUNE 14, 2011 At a firs ...
- 2017.6.30 安装IDEA的插件mybatis plugin(破解版)
参考来自:http://blog.csdn.net/u011410529/article/details/54098067 正常情况下的安装: 但是我的界面中找不到这个插件,而且这个插件是收费的. 1 ...
- ["1", "2", "3"].map(parseInt) 结果
// 下面的语句返回什么呢: ["1", "2", "3"].map(parseInt); // 你可能觉的会是[1, 2, 3] // 但 ...
- Oracle 修改表名
.ALTER TABLE T_PLAT_KEYWORD_STATISTIC RENAME TO T_PLAT_KEYWORD; .create new_table as select * from o ...
- mongo: 删
删除:remove db.CollectionName.remove(查询表达式,选项); 查询表达式:匹配要删除的文档,它是一个json对象 选项:{justOne:true/false},是否只删 ...