使用 Xtrabackup 在线对MySQL做主从复制【转】

3. 使用Percona-Xtrabackup恢复数据

这里假设比较简单的情况：全量备份，全量恢复，不涉及增量。

安装和具体使用，见文章。

赋予备份用户权限：

mysql> CREATE USER ‘bkpuser‘@‘localhost‘ IDENTIFIED BY ‘bkppass‘;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS,SUPER ON *.* TO ‘bkpuser‘@‘localhost‘;
mysql> FLUSH PRIVILEGES;

完整的选项使用请执行innobackupex –-help，这里只介绍使用常用的选项进行完整备份及增量备份和还原。

这一节是把数据恢复到从库，借此记录一下xtrabackup的使用（用了云之后，备份技能都丢了~）。生产环境你应该是早就有了xtrabackup的备份，做从库时只需要把备份拷过来，解压恢复。

假设 MySQL 安装目录在/opt/mysql，my.cnf配置文件/opt/mysql/my.cnf，端口3306，数据目录/opt/mysql_data，sock位于/opt/mysql_data/mysql.sock。备份数据放在/data/backup/mysql/。

3.1 全量备份

$ export BKP_PASS="bkppass"
$ innobackupex --defaults-file=/opt/mysql/my.cnf --host=localhost --port=3306 --user=bkpuser --password=${BKP_PASS} /data/backup/mysql

如果手头有一份未压缩的全备数据，要在另一台恢复，其实还不如直接 rsync 过来，将近400G的数据压缩与解压缩过程特别漫长。默认会以当天 日期+时间 戳命名备份目录，如 2015-09-16_00-00-02。一般会对它进行tar压缩，由于tar只能单进程，所以往往这个压缩过程会比备份过程耗时2倍还多。拷贝到需要恢复（做从库）的目录。

3.2 全量恢复

在恢复的数据库服务器（从库）上：

恢复准备
$ innobackupex --use-memory=16G --apply-log 2015-09-16_00-00-02
 
确认数据库是关闭的，并且datadir，目录下为空
$ innobackupex --defaults-file=/opt/mysql/my.cnf --use-memory=16G --copy-back 2015-09-16_00-00-02

4. 做从库第一步是恢复准备，apply-log应用全备时 log sequence number 之后的数据，完了后会输出类似 InnoDB: Last MySQL binlog file position 0 262484673, file name ./mysql-bin.000135 的信息，告诉我们了后面的从库应该从哪个地方开始复制。时间不会很长，但最好用screen之类的软件放到后台执行，以免终端断开，功亏一篑。 第二步使用新的my.cnf文件，将完整的mysql数据文件拷贝到datadir下。 

上面恢复过程最后一步apply-log完成之后，会得到一个lsn position 和binlog文件名：262484673、mysql-bin.000135。下面开始从库制作。

一般在copy-back之后需要修改数据文件目录的属性：

chown -R mysql.mysql /opt/mysql_data

4.1 my.cnf 

从库的配置文件简单一点可以从主库拷贝过来，但根据需要，要注意以下几处

• server-id一定不能与主库相同
  否则，会出现如下错误：
  Slave: received end packet FROM server, apparent master shutdown

• 从库一般作为只读库使用，所以为安全起见，设置只读 set global read_only=1;
  可以在从服务器的 my.cnf 里加入read-only参数来实现这一点，唯一需要注意的一点事read-only仅对没有super权限的用户有效。所以最好核对一下连接从服务器的用户，确保其没有super权限。

• 关于从库的事件
  MYSQL Replication 可以很好的达到你的预期：从库的事件不会自己去执行，主库会把event执行的结果直接同步。在statement模式下，复制的是 event BODY 里的SQL，在row模式下是主库事件执行完成后影响的行精确复制。

  从库 event_scheduler 参数是被忽略的，并且每个event 状态会是 SLAVESIDE_DISABLED ，但CREATE/ALTER EVENT等操作语句是会复制。主从切换后，从库事件状态会变成ENABLE。

• 参数调整
  从库是不允许写入的，否则数据就不一致了。从库实例的配置可以不要主库那么高，比如原16G的buffer pool，根据用途，从库可以设到4-8G（当时前提是将来你也不打算把它切换为主库用）。
  相应的，read_buffer_size，sort_buffer_size, query_cache_size 这些读相关参数可以略微增大。当然我一般都懒得去改。

• skip-slave-start
  主从创建完成后，默认情况下次启动从库，会自动启动复制进程，一般这也正是我们需要的，但在维护阶段时你可能不想从库启动后立即开始复制，--skip-slave-start选项可以帮到你。

• log-slave-updates
  正常情况从库是不需要写回放日志产生的binlog，无形中增加服务器压力。但如果你想要实现级联复制即 A -> B -> C ，B同时是A的从库，也是C的主库，就需要开启 log-bin 和 log-slave-updates 。

  另外，建议显示设置 log-bin=mysql-bin 确保主从正常切换。 show variables like ‘log%‘ 查看当前值。

• 关于过滤表见mysql-replica-filter

• sync_binlog
  For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master my.cnf file.

  上面的话同时也意味着性能最低。可以在这埋点，假如出现慢的情况，把两参数调成2。

4.2 启动从库

启动数据库，注意看日志

# /opt/mysql/bin/mysqld_safe --defaults-file=/opt/mysql/my.cnf &

提示：如果你不确定这个库是谁的从库，保守起见加上--skip-slave-start启动，兴许能防止数据不一致。

4.3 change master

在从库上

$ mysql -uslave_ali -p‘slave_ali_pass‘ -S /opt/mysql_data/mysql.sock
mysql> change master to master_host=MASTER_HOST, master_port=3306, 
       master_user=‘slave_ali‘,master_password=‘slave_ali_pass‘,
       master_log_file=‘mysql-bin.000135‘, master_log_pos=262484673;

上面的 master_log_file 和 master_log_pos 即是输出的值，也可以在新的数据目录下xtrabackup_binlog_info找到信息。

mysql> show slave status\G
mysql> start slave;
mysql> show slave status\G

4.4 验证同步延迟

从库执行 show slave status\G
节选：

Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
Relay_Log_File: slave1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 931
Relay_Log_Space: 408
Seconds_Behind_Master: 0


Master_Log_File： I/O线程当前正在读取的主服务器二进制日志文件的名称 

• Read_Master_Log_Pos：本机I/O线程读取主服务器二进制日志位置
  上面2各值，与在主库执行show master status;看到的值如果基本接近，说明从库IO线程已经赶上了主库的binlog。
• Relay_Master_Log_File: 由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称

• Exec_Master_Log_Pos: SQL线程执行来自master的二进制日志最后一个事件位置
  与上面的Relay_Master_Log_File一起，同Master_Log_File、Read_Master_Log_Pos比较，能看到SQL线程是否已经赶上从库本地的IO线程。

• Slave_IO_Running：I/O线程是否启动并成功连接到主服务器上
  一般和下面的Slave_IO_Running和Seconds_Behind_Master一起监控主从健康状态

• Slave_SQL_Running：SQL线程是否启动
• Seconds_Behind_Master: 从属服务器“落后”多少秒
  官网的解释是：The number of seconds that the slave SQL thread is behind processing the master binary log。但是当 SBM 为 0 时也不代表一定没有延迟，因为可能因为网络慢的缘故，从库的IO线程传输binlog太慢，它的SQL线程应用日志很容易就赶上relay log，但实际主库产生的binlog比传输的快，就会造成为0的假象。
  有时你反复status会发现 Seconds_Behind_Master 的值在0与一个很大的数之间波动，有可能是主库上执行了一个非常大的event，没执行完毕的时候从库SBM显示为0，event执行完成并传输完binlog后，就会显示SBM非常巨大。（我在从机房迁移mysql到阿里云上部分库老出现这种情况，应该跟网络和大event都有关系）。
  另外，relay log 中event记录的时间戳是主库上的时间戳，而SQL thread的时间戳是从库上的，如果主库和从库的时间偏差较大，那么这个SBM的意义就基本不存在了。

5. 参考

• 高性能Mysql主从架构的复制原理及配置详解
• How does MySQL Replication really work?
• XtraBackup不停机不锁表搭建MySQL主从同步实践
• MySQL复制原理与配置
• 许多模糊的内容还是看官网的

本文链接地址：http://seanlook.com/2015/12/14/mysql-replicas/

转自

使用 Xtrabackup 在线对MySQL做主从复制 | Sean‘s Notes
http://seanlook.com/2015/12/14/mysql-replicas/

使用 Xtrabackup 在线对MySQL做主从复制【转】

标签：解压缩   bsp   写入   更改   info   情况   load   下一步   ble