你的位置:首页 > 软件开发 > 数据库 > MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

发布时间:2016-06-15 15:00:06
第13章 可扩展性设计之 MySQL Replication前言:MySQL Replication 是 MySQL 非常有特色的一个功能,他能够将一个 MySQL Server 的 Instance 中的数据完整的复制到另外一个 MySQL Server 的 Instanc ...

MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

第13章 可扩展性设计之 MySQL Replication

前言:

MySQL Replication 是 MySQL 非常有特色的一个功能,他能够将一个 MyServer.aspx' target='_blank'>SQL Server 的 Instance 中的数据完整的复制到另外一个 MySQL Server 的 Instance 中。虽然复制过程并不是实时而是异步进行的,但是由于其高效的性能设计,延时非常之少。MySQL 的Replication 功能在实际应用场景中被非常广泛的用于保证系统数据的安全性和系统可扩展设计中。本章将专门针对如何利用 MySQL 的 Replication 功能来提高系统的扩展性进行详细的介绍。 13.1 Replication 对可扩展性设计的意义

互联网应用系统中,扩展最为方便的可能要数最基本的 Web 应用服务了。因为 Web应用服务大部分情况下都是无状态的,也很少需要保存太多的数据,当然 Session 这类信息比较例外。所以,对于基本的 Web 应用服务器很容易通过简单的添加服务器并复制应用程序来做到 Scale Out。 而数据库由于其特殊的性质,就不是那么容易做到方便的 Scale Out。当然,各个数据库厂商也一直在努力希望能够做到自己的数据库软件能够像常规的应用服务器一样做到方便的 Scale Out,也确实做出了一些功能,能够基本实现像 Web 应用服务器一样的Scalability,如很多数据库所支持的逻辑复制功能。 MySQL 复制的基本过程如下: 1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 如果要完全避免这些问题,就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的Cluster 知道笔者写这部分内容的时候,仍然还是一个内存数据库的解决方案,也就是需要将所有数据包括索引全部都 Load 到内存中,这样就对内存的要求就非常大的大,对于一般的大众化应用来说可实施性并不是太大。当然,在之前与 MySQL 的 CTO David 交流的时候得知,MySQL 现在正在不断改进其 Cluster 的实现,其中非常大的一个改动就是允许数据不用全部 Load 到内存中,而仅仅只是索引全部 Load 到内存中,我想信在完成该项改造之后的 MySQL Cluster 将会更加受人欢迎,可实施性也会更大。 13.2.2 复制实现级别

MySQL 的复制可以是基于一条语句(Statement Level),也可以是基于一条记录(Row level),可以在 MySQL 的配置参数中设定这个复制级别,不同复制级别的设置会影响到Master 端的 Binary Log 记录成不同的形式。 缺点:由于他是记录的执行语句,所以,为了让这些语句在slave端也能正确执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是,由于Mysql现在发展比较快,很多的新功能不断的加入,使mysql得复制遇到了不小的挑战,自然复制的时候涉及到越复杂的内容,bug也就越容易出现。在statement level下,目前已经发现的就有不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现,比如:sleep()函数在有些版本中就不能真确复制,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题。 一个Master复制多个 Slave 的架构实施非常简单,多个 Slave 和单个 Slave的实施并没有实质性的区别。在 Master 端并不 Care 有多少个 Slave 连上了自己,只要有 Slave 的 IO 线程通过了连接认证,向他请求指定位置之后的 Binary Log 信息,他就会按照该IO线程的要求,读取自己的 Binary Log 信息,返回给 Slave 的 IO 线程。 对于 Replication 的配置细节,在 MySQL 的官方文档上面已经说的非常清楚了,甚至介绍了多种实现 Slave 的配置方式,在下一节中我们也会通过一个具体的示例来演示搭建一个 Replication 环境的详细过程以及注意事项。

13.3.2 Dual Master 复制架构(Master - Master)

有些时候,简单的从一个 MySQL 复制到另外一个 MySQL 的基本 Replication 架构, 可能还会需要在一些特定的场景下进行 Master 的切换。如在 Master 端需要进行一些特别的维护操作的时候,可能需要停 MySQL 的服务。这时候,为了尽可能减少应用系统写服务的停机时间,最佳的做法就是将我们的 Slave 节点切换成 Master 来提供写入的服务。 通过 Dual Master 复制架构,我们不仅能够避免因为正常的常规维护操作需要的停机所带来的重新搭建 Replication 环境的操作,因为我们任何一端都记录了自己当前复制到对方的什么位置了,当系统起来之后,就会自动开始从之前的位置重新开始复制,而不需要人为去进行任何干预,大大节省了维护成本。 当然,我们也可以通过特殊的约定,让某些表的写操作全部在一端,而另外一些表的写操作全部在另外一端,保证两端不会操作相同的表,这样就能避免上面问题的发生了。

13.3.3 级联复制架构(Master - Slaves - Slaves ...)

在有些应用场景中,可能读写压力差别比较大,读压力特别的大,一个 Master 可能需要上10台甚至更多的 Slave 才能够支撑注读的压力。这时候,Master 就会比较吃力了, 因为仅仅连上来的 Slave IO 线程就比较多了,这样写的压力稍微大一点的时候,Master 端因为复制就会消耗较多的资源,很容易造成复制的延时。 当然,如果条件允许,我更倾向于建议大家通过拆分成多个 Replication 集群来解决上述瓶颈问题。毕竟 Slave 并没有减少写的量,所有 Slave 实际上仍然还是应用了所有的数据变更操作,没有减少任何写 IO。相反,Slave 越多,整个集群的写 IO 总量也就会越多,我们没有非常明显的感觉,仅仅只是因为分散到了多台机器上面,所以不是很容易表现出来。 这种 Dual Master 与级联复制结合的架构,最大的好处就是既可以避免主 Master 的写入操作不会受到 Slave 集群的复制所带来的影响,同时主 Master 需要切换的时候也基本上不会出现重搭 Replication 的情况。但是,这个架构也有一个弊端,那就是备用的Master 有可能成为瓶颈,因为如果后面的 Slave 集群比较大的话,备用 Master 可能会因为过多的 Slave IO 线程请求而成为瓶颈。当然,该备用 Master 不提供任何的读服务的时候,瓶颈出现的可能性并不是特别高,如果出现瓶颈,也可以在备用 Master 后面再次进行级联复制,架设多层 Slave 集群。当然,级联复制的级别越多,Slave 集群可能出现的数据延时也会更为明显,所以考虑使用多层级联复制之前,也需要评估数据延时对应用系统的影响。 1. Master 端准备工作 可以通过给一个现有帐户授予复制相关的权限,也可以创建一个全新的专用于复制的帐户。 当然,我还是建议用一个专用于复制的帐户来进行复制。在之前“MySQL 安全管理”部分也 已经介绍过了,通过特定的帐户处理特定一类的工作,不论是在安全策略方面更有利,对于维护来说也有更大的便利性。实现 MySQL Replication 仅仅只需要“REPLICATION SLAVE” 权限即可。可以通过如下方式来创建这个用户: ◆ 通过数据库全库冷备份 Snapshot 功能的文件系统上面(如 ZFS),或者我们的文件系统虽然不支持 Snapshot, 但是我们的文件系统运行在 LVM 上面,那么我们都可以通过相关的命令对 MySQL 的数据文件和日志文件所在的目录就做一个 Snapshot,这样就可以得到了一个基本和全库冷备差不多的备份集。 上面的操作我们还只是获得了合适的备份集,还没有该备份集所对应的 Log Position,所以还不能完全满足搭建 Slave 的要求。幸好 mysqldump 程序的开发者早就考虑到这个问题了,所以给 mysqldump 程序增加了另外一个参数选项来帮助我们获取到对应的 Log Position,这个参数选项就是 —master-data 。当我们添加这个参数选项之后,mysqldump会在 dump 文件中产生一条 CHANGE MASTER TO 命令,命令中记录了 dump时刻所对应的详细的 Log Position 信息。如下: 因为该命令并不是一个完整的 CHANGE MASTER TO 命令,如果在配置文件(my.cnf)中没有配置MASTER_HOST,MASTER_USER,MASTER_PASSWORD 这三个参数的时候,该语句是无法有效完成的。 13.5 小结

在实际应用场景中,MySQL Replication 是使用最为广泛的一种提高系统扩展性的设计手段。众多的 MySQL 使用者通过 Replication 功能提升系统的扩展性之后,通过简单的增加价格低廉的硬件设备成倍甚至成数量级的提高了原有系统的性能,是广大 MySQL 中低端使用者最为喜爱的功能之一,也是大量 MySQL 使用者选择 MySQL 最为重要的理由之一。

 

 

摘自:《MySQL性能调优与架构设计》简朝阳

转载请注明出处:

作者:JesseLZJ

原标题:MySQL性能调优与架构设计——第13章 可扩展性设计之 MySQL Replication

关键词:MYSQL

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。