Zabbix在线迁移方案（适用于MySQL5.7）

目录

术语、定义

迁移工具简介

架构图

前置检查

3.1. 检查主机物理内存

3.2. 检查磁盘空间

3.3. 检查操作系统版本

3.4. 检查当前主机IO情况

3.5. 检查当前MySQL服务器并发量

3.6. 检查当前MySQL服务器线程情况

3.7. 获取每一个数据库的大小

3.8. 获取每个库中不同存储引擎的表的个数

3.9. 存储准备

3.10. xtrabackup安装

数据库物理备份
4.1. xtrabackup部分参数说明

4.2. xtrabackup全量备份

4.2.1. 权限检查

4.2.2. 创建备份目录

4.2.3. 进行全量备份

4.2.4. 对全备prepare

4.2.5. 验证备份是否成功

物理备份创建从库
5.1. 挂载备份NAS盘

5.2. 创建实例

5.3. 备份恢复

5.4. 主从搭建

5.5. 数据检验

Zabbix应用切割
6.1. 修改主从Zabbix服务配置

6.2. 停止备zabbix机上keepalived服务

6.3. 重启主Zabbix服务

6.4. 启动备zabbix机上keepalived服务

6.5. Web界面重新配置

6.6. 应用验证

————

术语、定义
下列术语、定义和缩略语适用于本文。

词语 解释
zabbix 开源监控软件
keepalived 高可用软件
xtrabackup percona开源热备工具
binlog mysql记录所有修改数据据的二进制日志
mysqlbinlog mysql提供的二进制文件解析工具
InnoDB mysql另一个存储引擎，支持行锁、事务安全
MyISAM mysql中的一个存储引擎，不支持行锁、事务
.frm 表元数据文件，存储表结构的定义信息
.ibd InnoDB多表空间(独享)存储方式，每个表一个数据文件
ibdata InnoDB共享存储方式，所有表共享一个或多个数据文件
1 迁移工具简介
xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），是商业备份工具InnoDB Hotbackup的一个很好的替代品。xtrabackup有两个主要的工具：xtrabackup、innobackupex，xtrabackup只能备份InnoDB和XtraDB两种数据表，且只备份数据文件（.ibd），并不备份数据表结构文件（.frm），同时不能备份MyISAM数据表，所以使用xtrabackup恢复的时候，你必须有对应表结构文件(.frm)；innobackupex-1.3.1则封装了xtrabackup，是一个脚本封装，所以能同时备份处理InnoDB和MyISAM，但在处理MyISAM时需要加一个读锁。

2 架构图
图片
架构
3 前置检查
在全量备份，首先要确定需要备份的数据对象、备份数据库的大小和备份文件存放位置的空间大小，检查主机的基本情况。

3.1 检查主机物理内存

free -g
total used free shared buffers cached
Mem: 126 103 96 0 0 22
-/+ buffers/cache: 6 119
Swap: 124 0 124

3.2 检查磁盘空间

df -h
文件系统 容量 已用 可用 已用%% 挂载点
/dev/sda1 769G 229G 502G 32% /
tmpfs 64G 260K 64G 1% /dev/shm
/dev/sda3 940G 276G 617G 31% /app
/dev/mapper/Mysqlvg-Mysqllv
493G 349G 119G 75% /data
192.168.203.41:/mnt/zxdfs/CM_South15/root/cccloud_tenant_id10001154
1.0T 0 1.0T 0% /mysql
3.3 检查操作系统版本
#uname -a
Linux Mysqlmaster2 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
3.4 检查当前主机IO情况

iostat -cdx 2
图片

重点关注参数：%util 表示磁盘忙碌情况，一般该值超过80%表示该磁盘可能处于繁忙状态。
3.5 检查当前MySQL服务器并发量

mysqladmin extended -i1 -uroot -p -S /tmp/mysql.sock |grep Threads_running
图片

3.6 检查当前MySQL服务器线程情况
mysql> SELECT * FROM performance_schema.threads WHERE processlist_command<>‘sleep’ AND processlist_id IS NOT NULL\G
*************************** 1. row ***************************
THREAD_ID: 27
NAME: thread/sql/compress_gtid_table
TYPE: FOREGROUND
PROCESSLIST_ID: 1
PROCESSLIST_USER: NULL
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
PROCESSLIST_TIME: 1815110
PROCESSLIST_STATE: Suspending
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: 1
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: NULL
THREAD_OS_ID: 16362
*************************** 2. row ***************************
THREAD_ID: 101886
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 101860
PROCESSLIST_USER: repl
PROCESSLIST_HOST: 10.20.234.157
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Binlog Dump
PROCESSLIST_TIME: 177564
PROCESSLIST_STATE: Master has sent all binlog to slave; waiting for more updates
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: TCP/IP
THREAD_OS_ID: 24901
*************************** 3. row ***************************
THREAD_ID: 123682
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 123656
PROCESSLIST_USER: root
PROCESSLIST_HOST: localhost
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 0
PROCESSLIST_STATE: Sending data
PROCESSLIST_INFO: SELECT * FROM performance_schema.threads WHERE processlist_command<>‘sleep’ AND processlist_id IS NOT NULL
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: Socket
THREAD_OS_ID: 14484
*************************** 4. row ***************************
THREAD_ID: 94022
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 93996
PROCESSLIST_USER: repl
PROCESSLIST_HOST: 10.20.234.158
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Binlog Dump
PROCESSLIST_TIME: 259239
PROCESSLIST_STATE: Master has sent all binlog to slave; waiting for more updates
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: TCP/IP
THREAD_OS_ID: 31926
4 rows in set (0.00 sec)
3.7 获取每一个数据库的大小
mysql> SELECT TABLE_SCHEMA,CONCAT(ROUND(SUM(DATA_LENGTH)/1024/1024),‘MB’) AS DATA_LENGTH,CONCAT(ROUND(SUM(INDEX_LENGTH)/1024/1024),‘MB’) AS INDEX_LENGTH,CONCAT(ROUND(SUM(DATA_LENGTH+INDEX_LENGTH)/1024/1024),‘MB’) AS TOTAL_SIZE FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN(‘information_schema’,‘performance_schema’,‘mysql’,‘test’) GROUP BY TABLE_SCHEMA ORDER BY 4 DESC;
图片

3.8 获取每个库中不同存储引擎的表的个数
mysql> SELECT TABLE_SCHEMA,ENGINE,COUNT(1) AS C_TABLES FROM information_schema.TABLES WHERE TABLE_SCHEMA
NOT IN(‘information_schema’,‘performance_schema’,‘mysql’,‘sys’,‘test’) GROUP BY TABLE_SCHEMA, ENGINE ORDER BY 3 DESC;;
图片

3.9 存储准备
分配一块备份使用的NAS盘

3.10 xtrabackup安装
#配置好yum源

yum -y install perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-IO-Socket-SSL libev
#上传介质包到/tmp目录下

cd /tmp
rpm -ivh percona-xtrabackup-24-2.4.10-1.el7.x86_64.rpm
4 数据库物理备份
4.1 xtrabackup部分参数说明
这里介绍的是xtrabackup的部分参数，仅供参考

–defaults-file
指定my.cnf参数文件的位置[此配置文件里必须指定datadir]，全备、增备和恢复时要指定改参数，否则可能找不到datadir，特别注意该参数只能放在innobackupex命令后第一个参数的位置上。

–apply-log
同xtrabackup的–prepare参数,一般情况下,在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据 文件仍处理不一致状态。–apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。对于没有增量备份，只是全备的恢复，在恢复前对全备prepare时，要加上该参数。

–apply-log --redo-only
强制备份日志时只redo,跳过rollback,这在做增量备份时非常必要。对于全备+增量的恢复，在恢复之前，要分别对全备和增量做prepare,那么全备的prepare和每次增量的prepare 均要加上该参数–apply-log --redo-only，
不要只加–apply-log而忘记–redo-only。而对于最后一次增量的prepare, --redo-only可加可不加。

–copy-back
做数据恢复时将备份数据文件拷贝到mysql服务器的datadir

–remote-host=HOSTNAME
通过ssh将备份数据存储到进程服务器上

–stream=[tar]
备份文件输出格式, 该文件可在XtarBackup binary文件中获得。在使用参数stream=tar备份的时候，你的xtrabackup_logfile可能会临时放在/tmp目录下,如果你备份的时候并发写入较大的话，xtrabackup_logfile可能会很大(5G+),很可能会撑满你的/tmp目录,可以通过参数–tmpdir指定目录来解决这个问题.

–tmpdir=DIRECTORY
当有指定–remote-host or --stream时, 事务日志临时存储的目录, 默认采用MySQL配置文件中所指定的临时目录tmpdir

–use-memory=*
该参数在prepare的时候使用,控制prepare时innodb实例使用的内存

–databases=LIST
列出需要备份的databases,如果没有指定该参数,所有包含MyISAM和InnoDB表的database都会被备份

–slave-info
备份从库, 加上–slave-info备份目录下会多生成一个xtrabackup_slave_info 文件, 这里会保存主日志文件以及偏移, 文件内容类似于：CHANGE MASTER TO MASTER_LOG_FILE=’’, MASTER_LOG_POS=0

–incremental-basedir
指定之前完整备份的目录，该参数在增量备份时候使用

–incremental
将会生成新的目录用于存放增量备份数据，该参数在增量备份时候使用

–incremental-dir
指定增量备份与全库备份合并去建立一个新的全备份的目录，该参数在对备份文件做恢复之前的prepare操作时使用，要与–apply-log --redo-only 参数共同使用

–socket=SOCKET
指定mysql.sock所在位置，以便备份进程登录mysql, 全备和增备时要指定改参数，否则可能本地连接不上mysql

4.2 xtrabackup全量备份
4.2.1 权限检查
备份过程中系统用户需要对存放备份数据的系统文件目录具备读写执行权限，而对数据库进行备份的时候，建议具备下面的权限能力：

Reload，lock tables(除非指定–no-lock参数)以便具备flush tables with read lock能力；
Replication client 具备获得二进制文件备份的能力；
Create tablespace 具备恢复整个表空间，并导入表的能力；
Super 用于启动、关闭从服务器复制线程环境。
4.2.2 创建备份目录

mkdir -p /backup/mysql_backup
mount 192.168.0.13:/backup /backup/mysql_backup
4.2.3 进行全量备份
执行全备命令

innobackupex --defaults-file=’mysql参数文件的路径’
–user=root --password=root --socket=’SOCKET文件的路径’ /backup/mysql_backup/
innobackupex 重点参数：–defaults-file 、–socket(参数说明见文档3.1)
查看上述全备命令后的输出
Xtrabackup: The latest check point (for incremental): ‘470308686’
xtrabackup: Stopping log copying thread.
.>> log scanned up to (470308686)

//备份过程中会终止日志线程，并以上一次checkpoint作为日志备份时间点。
4.2.4 对全备prepare
全备prepare

innobackupex --defaults-file=’mysql参数文件的路径’ --user=root --password=root --socket=’SOCKET文件的路径’
–apply-log /backup/mysql_backup/

innobackupex 重点参数：–defaults-file 、–socket 、–apply-log(参数说明见文档4.1)
在这里值得注意的是：当前全库备份只备份至上文提到checkpoint ‘470308686’ 序号的事务及已经完成同步至磁盘中的数据。而已经执行，但还没有提交的事务仍然存放在内存中(innodb buffer)，导致当前数据文件处于非一致性状态。

假设当前要对全备进行恢复，则要利用回滚未提交的事务，使得数据文件处于一致状态，因此，在执行完整全备之后，切记要对全备执行一次prepare操作 （–apply-log），这点是十分重要的。执行–apply-log时，必须要指定之前的备份目录(因为需要获得正确的xtrabackup_checkpoints文件)。

默认情况下，–apply-log 参数，只调用系统 100M 内存，如果当前 innodb buffer pool 比较大，则同步内存中数据时间可能会比较长，可以通过定义内存大小加快备份速度， 如参数 --use-memory=4G。

4.2.5 验证备份是否成功
----当上面的操作看到以下信息时，说明全量备份已经成功
151205 12:22:42 innobackupex: completed OK!
当上面3.2.3（全备）和3.2.4（全备prepare）中的两次操作都出现innobackupex: completed OK!字符串时，才表示本次全量备份成功。

5 物理备份创建从库
5.1 挂载备份NAS盘
挂在主库的物理备份数据至新从库主机

mount 192.168.0.13:/backup /backup/mysql_backup
5.2 创建实例
使用实例创建脚本，创建一个空的mysql实例，用于物理备份的恢复。空实例创建完成后，停止该实例，并删除该实例下的部分文件。

（新从库主机上执行）

新的mysql空实例信息如下：
base_dir: /data/mysql/db_ngoc
配置文件：/data/mysql/db_ngoc/conf/ngoc.cnf

停止该实例
/data/mysql/db_ngoc/bin/shutdown.sh

删除该实例下的部分文件（删除前一定要确认清楚IP与实例路径）
cd /data/mysql/db_ngoc
rm -rf ./data/*
rm -rf ./ulog/*
rm -rf ./rlog/*
5.3 备份恢复
利用物理备份数据恢复至新建MYSQL空实例中

（新从库主机上执行）

备份文件恢复至空实例
innobackupex --defaults-file=/data/mysql/db_ngoc/conf/ngoc.cnf --copy-back /backup/mysql_backup
修改数据目录权限
chown mysql. -R /data/mysql
5.4 主从搭建
根据物理备份数据中“xtrabackup_info”文件记录的备份时刻的“gtid、position”信息，进行主从数据复制搭建，以进行数据间的时时同步.
图片

（新从库上执行）

启动mysql实例，并登陆
/data/mysql/db_ngoc/bin/startup.sh
/data/mysql/db_ngoc/bin/login.sh

清空master/slave相关信息
reset master;
reset slave all;
show master status;

设置数据同步起点GTID(来自：xtrabackup_info文件)
set global gtid_purged =“7d58ee1a-93a0-11e7-8ff5-f44c7f785650:1-3,d2cf8b03-939f-11e7-99db-407d0f46034d:1-14193879”

使用命令搭建主从
CHANGE MASTER TO
MASTER_HOST=’’,
MASTER_USER=’’,
MASTER_PASSWORD=’’,
MASTER_PORT=,
MASTER_AUTO_POSITION=1;

启动主从复制，并查看状态
start slave;
show slave status\G
5.5 数据检验
主从搭建完成后，进行主从数据条数的验证

主从分别执行以下命令
mysqlshow -u zabbix -pzabbix -S /data/mysql/db_ngoc/mysql.sock --count zabbix
主库执行结果
图片

从库执行结果
图片

6 Zabbix应用切割
6.1 修改主从Zabbix服务配置
（新Zabbix主备机上执行）

cp /zabbix/server/etc/zabbix_server.conf /zabbix/server/etc/zabbix_server.conf.bak
sed -i “s/DBHost=.*/<新从库地址>/g” /zabbix/server/etc/zabbix_server.conf
6.2 停止备zabbix机上keepalived服务

systemctl stop keepalived
6.3 重启主Zabbix服务
（主zabbix机上执行）

systemctl restart zabbix-server
6.4 启动备zabbix机上keepalived服务
（备zabbix机上执行）

systemctl stop keepalived
6.5 Web界面重新配置
浏览器访问：http:///setup.php
图片

图片

图片

6.6 应用验证
浏览器访问：http:///zabbix.php
图片
————————————————
版权声明：本文为CSDN博主「Zabbix_China」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Zabbix_China/article/details/121603827