mysql_wp_replication_tutorial

1. 介绍MySQL复制可以让用户经济有效地提供应用程序的性能,扩展性和高可用。世界上许多最繁忙的网络站点 像eBay，Facebook,Tumblr,Twitter 和YouTube 依赖MySQL 的复制来弹性的扩大,越过单实例的约束在实例间镜像数据,MySQL 复制是最常用的方法,提供高可用性。此外, MySQL 复制功能可以自动检测和recover from failures让用户保持服务由于停电或计划的维护。在5.6版本里,增强了mysql的复制,提供更高水平的数据完整性，性能,灵活性和自动化应用本文提供了一个简单的一步一步的指导如何安装和配置一个主从拓扑:以及处理故障转移事件（手动和自动）.他将展示如何容易的设置和使用新的service 使用最新的复制功能和 GlobalTransaction IDs (GTIDs) - introduced in MySQL 5.6.2. 自动复制 配置 使用MySQL 复制功能  GTIDsMysql 5.6的复制特性 GTIDs ，配置,监控和管理复制 变得更加简单和稳健。举个例子,它介绍了自动提升一个slave 为master 在原来的master fails的时候最简单的方式来访问这些功能是通过点击pocket-knife 按钮在MySQL WorkBench 支持failover 和恢复是更广泛的MySQL的功能 简化了MySQL 的维护和管理包括提供了复制的校验, 比对和cloning 数据库, 诊断。这个部分介绍如何使用这些工具来:1. 设置复制从单一的master 到多个slaves2.自动检测到master 的failure 提升其中的一个slaves 成为新的master3.介绍老的master 回归到拓扑作为一个新的slave， 提升它为master 至少我们需要增加哪些选项到[mysqld] 部分,（注意有些是指定给master的或者slave的,包括他们所有的server，使得角色切换变的简单)1.binlog-format: 基于行的复制被选为了测试所有的MySQL 5.6优化2.log-slave-updates, gtid-mode, enforce-gtid-consistency, report-port andreport-host:用于让 Global Transaction IDs  ,满足相关的条件。3.master-info-repository and relay-log-info-repository: 设置为TABLE 来启用crash-safe binlog/slave 功能（存储信息到事务表里相比文件)mysql> show variables like '%master%';+------------------------+-------+| Variable_name          | Value |+------------------------+-------+| master_info_repository | FILE  |mysql> show variables like '%relay%';+---------------------------+----------------+| Variable_name             | Value          |+---------------------------+----------------+| relay_log_info_repository | FILE 4.sync-master-info: set to 1 to ensure that no information is lost注意:为最大可能的耐久性和一致性，在使用InnoDB复制设置事务,你需要设置innodb_flush_log_at_trx_commit=1,sync_binlog=1 选项。mysql> show variables like '%innodb_flush_log_at_trx_commit%';+--------------------------------+-------+| Variable_name                  | Value |+--------------------------------+-------+| innodb_flush_log_at_trx_commit | 1     |+--------------------------------+-------+1 row in set (0.02 sec)mysql> show variables like '%sync_binlog%';+---------------+-------+| Variable_name | Value |+---------------+-------+| sync_binlog   | 0     |+---------------+-------+1 row in set (0.00 sec)sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。一般设置为1MySQL 5.6包括的按组提交的功能用于binlog 显著降低了master的负载功能事迹上是从运行在远端的host , 需要访问每个MySQL Servers. 因此用户必须被授予远程访问权限[billy@black ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITHGRANT OPTION;"[billy@blue ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITHGRANT OPTION;"[billy@green ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITHGRANT OPTION;"[billy@brown ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITHGRANT OPTION;"[billy@red ~]$ mysql -h 127.0.0.1 -P3306 -u root -e "GRANT ALL ON *.* TO root@'%' WITHGRANT OPTION;"在这个例子中, root 访问被授予了所有的远程主机(root@'%") 为了方便,对于一个安全生产环境 你需要有所选择。设置复制: 当这里有额外的选项(比如 指定用户名/密码 用于复制用户 或者提供root 用户的密码)mysqlreplicate --master=root@black:3306 --slave=root@blue:3306# master on black: ... connected.# slave on blue: ... connected.# Checking for binary logging on master...# Setting up replication...# ...done.mysqlreplicate --master=root@black:3306 --slave=root@green:3306# master on black: ... connected.# slave on green: ... connected.# Checking for binary logging on master...# Setting up replication...# ...done.mysqlreplicate --master=root@black:3306 --slave=root@brown:3306# master on black: ... connected.# slave on brown: ... connected.# Checking for binary logging on master...# Setting up replication...# ...done.mysqlreplicate --master=root@black:3306 --slave=root@red:3306# master on black: ... connected.# slave on red: ... connected.# Checking for binary logging on master...# Setting up replication...# ...done.复制已经被设置了 一个master 4个slaves我们可以验证复制拓扑匹配使用mysqlrplshow实用设计：mysqlrplshow --master=root@black --discover-slaves-login=root@black# master on utils1: ... connected.# Finding slaves for master: black:3306# Replication Topology Graphblack:3306 (MASTER)|+--- blue:3306 - (SLAVE)|+--- green:3306 - (SLAVE)|+--- brown:3306 - (SLAVE)|+--- red:3306 - (SLAVE)此外, 你也可以检查 复制环境是否配置正确:mysqlrplcheck --master=root@black --slave=root@brown:3306 --discover-slaves-login=root@black# master on black: ... connected.# slave on brown: ... connected.Test Description Status---------------------------------------------------------------------------3. 手动配置MySQL 复制在这个章节 我们描述一个替代,更加手工的方法用于设置MySQL replication.你可能使用这个,例如，如果GTIDs不是一种选择，因为你将使用MyISAM表,约束使用MySQL pre-5.6版本或需要额外的控制水平。尽管, 本程序是用建立一个slave的条款。有关示例说明。MasterHost Name: blackIP: 192.168.0.31SlaveHost Name: blueIP: 192.168.0.34图2应用程序配置为例我们假设你将要使用InnoDB 存储引擎(GTIDs的使用受到限制否则）为了包括更复杂的用例, 例子假设 MySQL Server 用于master的已经在使用和包含数据,如果启动一个空的数据库Ifstarting with an empty database then Step 3: and Step 4: can be skipped兼容性如果你尝试设置复制 在两个MySQL Server 已经安装好的机器，确保 MySQL master和slave 的版本是兼容的请注意，本节介绍了如何进行收到配置，参考2节看这可以大大简化和自动化使用MySQL复制工具Step 1: Configure the master & slave cnf files第一步是设置复制编辑my.cnf文件 在server上, 我们必须提供master 和slave的配置文件现在,重新启动Mysql servers 使用service manager 或者直接从命令行启动[billy@black ~]$ mysqladmin -u root shutdown # only needed if MySQL already running[billy@black ~]$ mysqld --defaults-file=/home/billy/mysql/black.cnf &[billy@blue ~]$ mysqladmin -u root shutdown # only needed if MySQL already running[billy@blue ~]$ mysqld --defaults-file=/home/billy/mysql/blue.cnf&注意:如果slave 已经先前被复制了, 启动slave server 带上--skip-slave-start 选项它不会理解去连master， 你也需要启动slave server 带上--log-warnings 选项来捕捉和得到更多额外的错误信息。这个选项默认是启用的Step 2: Create Replication User      下面的步骤是设置用于复制的在master 上创建一个账户用于复制。我们强烈推荐专用的复制用户为了更好的安全性,我们不需要赋额外的权限。 在master上创建一个账户用于slave连接,如前所述，这个账户必须授予REPLICATION SLAVE 权限。你可以执行GTANT 在mysql客户端或者MySQL WorkBench:[billy@black ~]$ mysql -u root --prompt='master> ' master> CREATE USER repl_user@192.168.0.34;master> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';Step 3: Lock the Master, Note Binlog Position and Backup MasterDatabase锁住master，记录Binlog 的Posistion 和备份Master 数据库这是一个可选的步骤,只有在如果新的master 先前已经接收更新 启用了binary logs或者由于时间久了 一些binary logs 已经被删除了,在master 上flush 所有的表阻塞写 通过FLUSH TABLESWITH READ LOCK 语句。master> FLUSH TABLES WITH READ LOCK;当read lock 生效后, 记录master 的binary log 和 offset 使用下面的语句:master> SHOW MASTER STATUS; +-------------------+----------+--------------+------------------+------------------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+-------------------+----------+--------------+------------------+------------------------------------------+| black1-bin.000006 | 1174 | | | A0F7E82D-3554-11E2-9949-080027685B56:1-5 |+-------------------+----------+--------------+------------------+------------------------------------------+文件显示binlog 的名字和posisiton  the binary log file is black1-bin.000006 and the Position is 1174在设置slave的时候 你需要这些值(除非你使用GTIDs, GTIDs不需要).它们藐视了 slave开始处理从master 接收新的更新的起点注意:如果master 已经之前运行了但是没有启动binlog，log name 和position 值显示为空的 在show master status下一步, 在先前执行FLUSH TABLE WITH READ 的窗口,你需要dump master的数据,在我们的例子中,我们dump clusterdb数据库的内容。注意：你可能不需要复制mysql 系统数据库,如果slave 有不同于Master的用户密码设置。在这种情况下,你需要在备份的时候排除。[billy@black ~]$ mysqldump -u root clusterdb > /home/billy/mysql/clusterdb.sqlYou can re-enable write activity on the master with the following statement:master> UNLOCK TABLES;Step 4: Load the Dump File on the Slave ( 在Slave上加载Dump 文件)下一步,加载数据[billy@blue ~]$ mysql -u root –e ‘create database clusterdb;’[billy@blue ~]$ mysql -u root clusterdb < /home/billy/mysql/slave/clusterdb.sqlStep 5: Initialize Replication你现在可以开始在slave上初始化复制, 执行下面的语句 如果已经作为slave运行了slave> STOP SLAVE;下一步,你需要使用一个CHANGE MASTER 语句,如果你使用GTIDs那么binary log 的position 信息是可选的使用MASTER_AUTO_POSITION会确认 正确的复制events 从master 发送到slaveslave> CHANGE MASTER TO MASTER_HOST='black', MASTER_USER='repl_user',MASTER_PASSWORD='billy', MASTER_AUTO_POSITION=1;Where:MASTER_HOST: the IP or hostname of the master server, in this example black or 192.168.0.31If not using GTIDs then you must provide positioning information for the master’s binary log:slave> CHANGE MASTER TO MASTER_HOST='192.168.0.31',-> MASTER_USER='repl_user',-> MASTER_PASSWORD='billy',-> MASTER_LOG_FILE='black-bin.000006',-> MASTER_LOG_POS=1174; Where:MASTER_LOG_FILE: is the file name we determined in Step 3:MASTER_LOG_POS: is the position we determined in Step 3:Finally, start replication on the slave:slave> START SLAVE;5. 复制管理和Troubleshooting在这一节中我们将如何执行一些基本的管理和故障排除任务MySQL复制。1.检查复制状态:最常见的任务在管理复制的时候是确保复制是在运行的 ,在master 和slave 上没有任何的错误:slave> SHOW SLAVE STATUS\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.1.31Master_User: repl_userMaster_Port: 3306Connect_Retry: 60Master_Log_File: black-bin.000006Read_Master_Log_Pos: 1655Relay_Log_File: blue-relay-bin.000004Relay_Log_Pos: 1867Relay_Master_Log_File: black-bin.000006Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 1655Relay_Log_Space: 2235Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 1Master_UUID: 5c9a887f-3983-11e2-b48f-080027685b56Master_Info_File: mysql.slave_master_infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O threadto update itMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set: 5C9A887F-3983-11E2-B48F-080027685B56:1-6Executed_Gtid_Set: 5C9A887F-3983-11E2-B48F-080027685B56:1-6,5FB9D4B7-3983-11E2-B48F-0800274BDCE7:1-21.Slave_IO_State  表明当前slave的状态Slave_IO_State: Waiting for master to send event2. Slave-IO-Running 显示 IO thread 读取master的binary log 是否运行Slave_IO_Running: Yes3.Slave_SQL_Running 显示SQL thread 是否执行relay log里的eventsSlave_SQL_Running: Yes4.Last_Error: 显示处理relay log 最后的错误日志，空表示没有错误 Last_Error: 5.Seconds_Behind_Master： 显示 salve 的SQL thread 是落后master binary log 多少秒了,一个比较大的值 表明slave五福应付大量的master的更新语句。 值为0说明slave已经追上了master,但是某些情况下这不是完全正确的。Seconds_Behind_Master: 0注意 当使用GTIDs的时候,Retrieved_Gtid_Set and Executed_Gtid_Set提供了 信息干预GTIDs已经接收和处理Suspending Replication 复制挂起你可以停止和启动复制 使用STOP SLAVE 和START SLAVE停止执行binary log 使用STOP SLAVE;slave> STOP SLAVE;当执行被停止, slave不从master 读取binary log 通过IO_THREAD 停止从relay log 处理events通过SQL_THREAD  你可以单独停止IO或者SQL thread通过下面的命令：slave> STOP SLAVE IO_THREAD;停止SQL thread 可能是有用的 ,如果你需要执行一个office backup 或者其他任务在slave上 只处理master 的eventIO thread 会继续读取master，但是改变不会被应用, 这将使slave更容易追上,当你再次启用slave的时候 ，这个是重要的 当你让这个slave 成为新得master的时候。停止IO thread 允许relay log里的语句被执行直到 中继日志停止接收新的events.使用这个选项是有用的,当你需要允许slave 来追赶master，当你需要在slave上执行管理任务但是不确定是否更新到一个特定的点。6 Manual Failover and Recovery手动Failover 和Recovery会有些时候,master fails或者需要进行维护,这个章节需要的步骤:步骤1 ：先决条件在章节2和章节4 我们配置了复制有2个MySQL Server 在一个master-slave 配置1.所有的关系被改变 --一个server 表现为slave 可以变为Master(例子 当你需要shutdown 原来的master用于维护)原来的master 可以随后变为slave2.我们开始更加复杂的配置  一个单独的master 和2个slave