MySQL主从部署方案最佳实践（ word 版）.docxVIP

PAGE PAGE 10 MySQL 主从部署方案最佳实践 1、概述 从本篇文章开始我们将花一定的篇幅向读者介绍 mysql 的各种服务集群的搭建方式。大致的讨论思路是从最简的 MySQL 主从方案开始介绍，通过这种方案的不足延伸出更复杂的集群方案，并介绍后者是如何针对这些不足进行改进的。 MySQL 的集群技术方案特别多，这几篇文章会选择一些典型的集群方案向读者进行介绍。 2、MySQL 最简单主从方案及工作原理 我们讲解的版本还是依据目前在生产环境上使用最多的 version 5.6 进行，其中一些特性在Version 5.7 和最新的 Version 8.0 中有所改进，但这不影响读者通过文章去理解构建 MySQL 集群的技术思路，甚至可以将这种机制延续到 MariaDB 。例如马上要提到的 MySQL 自带的日志复制机制（ Replicaion 机制）。 MySQL 自带的日志复制机制称为 MySQL-Replicaion 。从 MySQL 很早的 Version 5.1 版本就有 Replicaion 技术，发展到现有版本该技术已经非常成熟，通过它的支持技术人员可以做 出多种 MySQL 集群结构。当然，后文我们还会介绍一些由第三方软件 /组件支持的 MySQL 集群方案。 、MySQL-Replicaion 基本工作原理 Replicaion 机制从技术层面讲，存在两种基本角色： Master 和 Salve 。Master 节点负责在 Replicaion 机制中，向一个或者多个目标输出数据，而 Salve 节点负责在 Replicaion 机制中接受 Master 节点传来的数据。在实际业务环境下， Master 节点和 Salve 节点还分别有另外一个名字： Write 节点和 Read 节点——是的，利用 Replicaion 机制我们可以搭建以读写分离为目标的 MySQL 集群服务。但是为了保证读者在阅读文章内容时不会产生歧义，在本文（和 后续文章）中我们都将使用 Master 节点和 Salve 节点这样的称呼。Replicaion 机制依靠 MySQL 服务的二进制日志同步数据： 如上图所示， Salve 在启动后会建立一个和 Master 节点的网络连接，当 Master 节点的二进制日志发生变化后， 一个或者多个 MySQL Salve 服务节点就会通过网络接监听到这些变化日志。接着 Salve 节点会首先在本地将这些变化写入中继日志文件（ Relay Log ），这样做是为了尽量避免 MySQL 服务在出现异常时同步数据失败，其原理和之前介绍过的 InnoDB Log 的 工作原理相似。当中继日志文件发生完成记录后， MySQL Salve 服务会将这些变化反映到对应的数据表中，完成一次数据同步过程。 最后 Salve 会更新重做日志文件中的更新点（ Position ）， 并准备下一次 Replicaion 操作。 在这个过程中多个要素都可以进行配置， 例如可以通过 sync_binlog 参数配置 Master 节点上数据操作次数和日志写入次数配比关系、可以通过 binlog_format 参数配置日志数据的信息结构、可以通过 sync_relay_log 参数配置 Salve 节点上系统接收日志数据与写入中继日志文件 次数的配比关系。这些参数和其它一些在示例中使用的参数会在本文后续小节进行介绍。 、MySQL 一主多从搭建方式 介绍完 MySQL Replicaion 机制的基本工作方式后，我们紧接着就来快速搭建由一个 Master 节点和一个 Salve 节点构成的 MySQL 集群。读者可以从这个一主一从的 MySQL 集群方案扩展出任何一主多从的集群方案： 这个实例我们使用 Version 5.6 版本进行设置，当然 version 5.7 版本的安装也是类似的。另外，在 linux 操作系统上（ Centos 5.6/5.7/6.X ）安装 MySQL 服务和进行基本设置的过程， 由于篇幅和文章定位原因这里就不再进行赘述。 我们将分别在如下 ip 的 Linux 操作安装集群的 Master 节点和 Salve 节点： MySQL Master 服务： 40 MySQL Salve 服务： 41 、设置 Master 服务器 首先需要更改 MySQL Master 服务 f 主配置文件的信息，主要目的是开启 Master 节点上的二进制日志功能（注意这里说的日志并不是 InnoDB 引擎日志）。 # f 文件中没有涉及 Replicaion 机制的配置信息， # f 文件中没有涉及 Replicaion 机制的配置信息， 就不在这里列出了 #