MySQL5.6replicate容灾方案.docx

MySQL 5.6 replicate容灾方案MySQL 5.6 replicate容灾方案目 录1 文档介绍41.1 文档目的41.2 文档范围41.3 读者对象41.4 作业内容和范围41.5 术语与缩写解释42 MYSQL REPLICATE概述52.1 MySQL replicate原理52.2 MySQL replicate架构63 MYSQL REPLICATE安装配置73.1 安装MySQL73.2 配置MySQL replicate73.3 优化MySQL replicate84 MYSQL REPLICATE测试94.1测试主备数据一致性94.2 测试主备数据延迟95 常见问题处理115.1 MySQL replicate数据同步问题115.2 MySQL权限问题115.3 redo日志问题115.4 sock位置问题121 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 作业内容和范围1.5 术语与缩写解释2 MySQL replicate概述2.1 MySQL replicate原理 说明： MySQL作为常用生产数据库中的一种，容灾及高可用方面设计是必须考虑的。而MySQL replicate是容灾、负载均衡、读写分离、高可用性等技术的基础，不仅使用广泛且易于扩展，是一项成熟的技术。成功的商业案例如：replicate+MHA;replicate+corbar;replicate+MMM等。本章节主要介绍MySQL replicate原理及架构为安装配置replicate做技术储备。1、MySQL replicate复制常见用途：1）数据容灾：复制是备份的扩展方案，但不能直接取代备份；2）负载均衡：通过复制可以将读操作分布到多个服务器上；3）高可用性：能避免单点故障，一个包含复制的良好设计系统能够显著缩短宕机时间；4）MySQL升级：复制也是作为常用升级测试的解决方案。2、MySQL replicate复制原理：复制原理图1) 在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。MySQL会按事务提交的顺序而非每条语句执行的顺序来记录二进制日志。在记录二进制日志后，主库会告诉存储引擎可以提交事务了。2) 备库将主库的二进制日志复制到本地中继日志中。备库会启动一个IO线程，IO线程跟主库建立一个普通的客户端连接，然后再主库上启动一个特殊的二进制（binlog dump）线程，这个二进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，知道主库发送信号通知其有新的事件产生时才会被唤醒，备库IO线程会将接受到的事件记录到中继日志中。3) 备库启动SQL线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上IO线程时，中继日志通常已经在系统缓存中，所以中继日志开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写入其自己的二进制日志中。2.2 MySQL replicate架构1、一主多备在有少量写和大量读时，这种配置非常有用。可以把读分摊到多个备库上，直到备库给主库造成了太大的负担，或者主备之间的带宽成为瓶颈为止。尽管这是非常简单的拓扑结构，但它非常灵活，能满足多种需求。它的用途：1）为不同的角色使用不同的备库（例如添加不同的索引或使用不同的存储引擎）2）把一台备库当作待用的主库，除了复制没有其他数据传输。3）将一台备库放到远程数据中心，用作灾难恢复4）延迟一个或多个备库，以备灾难恢复5）使用其中一个备库，作为备份、培训、开发或者测试使用服务器。2、主动-主动模式下主-主复制主-主复制也叫双向复制包含两台服务器，每一个都配置成对方的主库和备库。一个可能的应用场景是两个处于不同地理位置的办公室，并且都需要一份可写的数据拷贝。这种配置最大的问题是如何解决冲突，两个可写的互主服务器导致的问题非常多。通常发生在两台服务器同时修改一行记录，或同时在两台服务器上向一个包含auto_increment列的表里插入数据。总体来说，允许向两个服务器上写入所带来的麻烦远远大于其带来的好处。3、主动-被动模式下主-主复制这种的主要区别在于其中一台服务器是只读的被动服务器。这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是对称的。这使得故障转移和故障恢复很容易。它也可以让你在不关闭服务器的情况下执行维护、优化表、升级操作系统或其他任务。设置主动-被动的主-主拓扑结构在某种意义上类似于创建一个热备份，但是可以使用这个“备份”来提高性能，例如，用它来执行读操作、备份、“离线”维护以及升级等。真正的热备份做不了这些事情。然后，不会得到比单台服务器更好的写性能。4、主库、分发主库以及备库当备库足够多时，会对主库造成很大负载。每个备库会再主库上创建一个线程，并执行binlog dump命令。该命令会读取二进制日志文件中的数据并将其发送到备库。每个备库都会重复这样的工作，它们不会共享binlog dump的资源。因此，如果需要多个备库，一个好办法是从主库移出负载并使用分发主库。分发主库事实上也是一个备库，它的唯一目的就是提前和提供主库的二进制日志。多个备库连接到分发主库，这使原来的主库拜托了负担。为了避免在分发主库上做实际的查询，可以将它的表修改为blackhole存储引擎。3 MySQL replicate安装配置3.1 安装MySQL省略3.2 配置MySQL replicate说明：配置复制的基本步骤总共三步：1、 在每台服务器上创建复制账号；2、 配置主库和备库；3、 通知备库连接到主库并从主库复制数据。1、 创建复制账号（主备库都创建）：mysqlgrant replication slave,replication client on *.* to repl192.168.0.% identified by password;2、 配置主库和备库主库配置参数：log_bin = /var/lib/mysql/mysql-binserver_id = 10binlog_format=ROW备库配置参数：lob_bin = mysql-binserver_id = 20relay_log = /var/lib/mysql/mysql-relay-binlog_slave_updates = 1read_only = 13、启动复制备库执行mysqlchange master to master_host=server1,master_user=repl,master_password=11,master_log_file=mysql-bin.000001,master_log_pos=0;4、主备库查看复制状态：主库状态检查：mysqlshow master status;备库状态检查：mysqlshow slave statusG;3.3 优化MySQL replicate说明：有许多参数来控制复制，其中一些会对数据安全和性能产生影响。为降低问题发生概率，下面配置参数建议设置。1、主库优化参数设置：sync_binlog=1innodb_flush_log_at_trx_commit=1expire_logs_days=8参数详解：sync_binlog：开启此选项MySQL每次在提交事务前会将二进制日志同步到磁盘上，保证不丢失事件；innodb_flush_log_at_trx_commit：每次提交及刷新日志，和sync_binlog配合设置保证主库布丢失事件；expire_logs_days：设置binlog保留时间，避免因binlog过快增长撑暴磁盘。2、备库优化参数设置：expire_logs_days=8binlog_format=ROWskip_slave_startsync_master_info= 1000sync_relay_log_info= 1000参数详解：expire_logs_days：设置binlog保留时间，避免因binlog过快增长撑暴磁盘；binlog_format：设置复制模式；skip_slave_start：关闭slave自动开启复制；sync_master_info：同步文件的方式；sync_relay_log_info：同步文件的方式。4 MySQL replicate测试4.1测试主备数据一致性说明：检查主备数据一致性应该是一个日常工作，特别是当使用备库来做备份时尤为重要，而MySQL本身是没有工具来检查主备数据一致性的。所以我推荐使用percona toolkit工具集里的pt-table-checksum来检测。它的原理是在主库中对数据进行校验并将结果插入到一个表中，通过复制传递到备库后在备库也进行校验一遍。然后和主库的校验结果比较是否一致。1、安装percona toolkt工具集主备库都需要安装#Yum y install perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-IO-Socket-SSL# rpm -Uvh percona-toolkit-2.2.1-2.noarch.rpm2、创建检查数据一致性账号Mysqlgrant select,process,super,replication slave on *.* to checksumsIP identified by password;Mysqlgrant create,alter,drop,select,insert,update,delete on csrep.* to checksumsIP;Mysqlflush privileges; 3、检查数据一致性状态在主库执行# pt-table-checksum h=5,u=checksums,p=123,P=3306 -d csrep -nocheck-replication-filters -replicate=csrep.checksums -no-check-binlog-format参数详解：-nocheck-replication-filters ：不检查复制过滤器，建议启用。后面可以用-databases来指定需要检查的数据库-no-check-binlog-format : 不检查复制的binlog模式，要是binlog模式是ROW，则会报错-replicate= ：把checksum的信息写入到指定表中，建议直接写到被检查的数据库当中-databases= ：指定需要被检查的数据库，多个则用逗号隔开-tables= ：指定需要被检查的表，多个用逗号隔开4、修复主备数据不一致数据-在备库执行# pt-table-sync -print -sync-to-master h=9 -d csrep -t data11 P=3306,u=checksums,p=123;参数详解：-print：只打印出不一致的结果但是并不直接修改- sync-to-master：以主库的数据作为模版检查4.2 测试主备数据延迟说明：虽然show slave status输出的seconds_behind_master列理论上显示了备库的延时，但由于各种各样的原因，并不总是准确的。最好的解决办法是使用heartbeat record，这是一个在主库上会每秒更新一次的时间戳。为了计算延时，可以直接用备库当前的时间戳减去心跳记录的值。这个方法还可以知道备库当前的复制状况。1、 开启后台进程（前提条件master与slave时间同步；replicate数据一致）-主库#pt-heartbeat -user=root -ask-pass -host=localhost -create-table -D csrep -interval=1 -update -replace -daemonize2、检查后台进程状态# pgrep -fl pt-heartbeat3、测试主备复制延迟#pt-heartbeat -user=checksums -password=123 -D csrep -create-table -interval=1 -frames=1s,2s,3s -master-server-id=15 -print-master-server-id -table=heartbeat -monitor -h 9参数详解：-create-table：在主上创建心跳监控的表，如果该表不存在。可以自己建立，建议存储引擎改成memory。通过更新该表知道主从延迟的差距；-interval：检查、更新的间隔时间。默认是见是1s。最小的单位是0.01s，最大精度为小数点后两位，因此0.015将调整至0.02；-frames 【-frames=1m,2m,3m】：在-monitor里输出的里的记录段，默认是1m,5m,15m。可以指定1个，如：-frames=1s，多个用逗号隔开。可用单位有秒（s）、分钟（m）、小时（h）、天（d）；-master-server-id：指定主的server_id，若没有指定则该工具会连到主上查找其server_id；-print-master-server-id在-monitor和-check 模式下，指定该参数则打印出主的server_id；-table：指定心跳表名，默认heartbeat；-monitor：持续监控从的延迟情况。通过-interval指定的间隔时间，打印出从的延迟信息，通过-file则可以把这些信息打印到指定的文件。4、关闭后台进程#pt-heartbeat -stop#rm -rf /tmp/pt-heartbeat-sentinel5 常见问题处理5.1 MySQL replicate数据同步问题因为binlog是记录修改了什么内容而不是记录修改后的内容，所以在同步前一定要保证master和slave要同步的数据库中内容完全相同。5.2 MySQL权限问题1问题现象rootuz6520 data# service mysql startStarting MySQL.The server quit without updating PID filFAILED/mysql/uz6520.pid).2问题分析rootuz6520 mysql# more uz6515.err2014-12-12 11:32:53 30726 ERROR Fatal error: Cant open and lock privilege tables: Table mysql.user doesnt exist此类问题是由于在编译安装时数据目录都是在软件目录下的data中，如果人为修改basedir数据目录位置后，启动mysql时就会找不到权限表。3解决方法rootuz6520 mysql# mv /usr/local/mysql/data/* /data/mysql/ #移动数据目录位置rootuz6520 data# cd /datarootuz6520 data# chown -R mysql:mysql mysqlrootuz6520 data# chmod -R ug+rwx mysql5.3 redo日志问题1问题现象rootuz6520 data# service mysql startStarting MySQL.The server quit without updating PID filFAILED/mysql/uz6520.pid).2问题分析2014-12-12 11:52:54 32317 ERROR InnoDB: Log file ./ib_logfile2 is of different size 104857600 bytes than other log files 50331648 bytes!2014-12-12 11