如何将阿里云的mysql（RDS）数据备份到本地

本例以本地服务器为 RHEL6/x64 系统，备份文件存储路径为 /home/mysql/ 为例。

下载云数据库 物理备份文件 并上传至目标服务器。备份文件获取方法请参见 下载备份数据。如果目标服务器可以访问源实例，您也可以使用 wget "url" 下载备份文件。其中 url 为备份文件下载地址。

切换路径到备份文件所在路径。

cd /home/mysql/

解压备份文件。

其中，filename.tar.gz 为备份文件名。

tar vizxf filename.tar.gz

检查解压后文件包含的数据库是否正确。

系统显示如下，其中 db0dz1rv11f44yg2、mysql 和 test 为云数据库中存在的数据库。

-rw-r--r-- 1 root root       269 Aug 19 18:15 backup-my.cnf

drwxr-xr-x 2 root root      4096 Aug 21 10:31 db0dz1rv11f44yg2

-rw-rw---- 1 root root 209715200 Aug  7 10:44 ibdata1

drwxr-xr-x 2 root root      4096 Aug 21 10:31 mysql

drwxr-xr-x 2 root root      4096 Aug 21 10:31 test

-rw-r--r-- 1 root root        10 Aug 19 18:15 xtrabackup_binary

-rw-r--r-- 1 root root        23 Aug 19 18:15 xtrabackup_binlog_info

-rw-r--r-- 1 root root        77 Aug 19 18:15 xtrabackup_checkpoints

-rw-r--r-- 1 root root      2560 Aug 19 18:15 xtrabackup_logfile

-rw-r--r-- 1 root root        72 Aug 19 18:15 xtrabackup_slave_info

cd filename/

ll

恢复数据文件。

系统显示 innobackupex: completed OK!，则数据恢复成功。

innobackupex --defaults-file=./backup-my.cnf --apply-log ./

修改配置文件。将解压文件 backup-my.cnf 中的 innodb_fast_checksum、innodb_page_size、innodb_log_block_size注释掉，并且添加 datadir=/home/mysql，如下所示。

# This MySQL options file was generated by innobackupex-1.5.1.

# The MySQL Server

[mysqld]

innodb_data_file_path=ibdata1:200M:autoextend

innodb_log_files_in_group=2

innodb_log_file_size=524288000

#innodb_fast_checksum=0

#innodb_page_size=16364

#innodb_log_block_size=512

datadir=/home/mysql/

重装 MySQL 系统库，取得数据库的 root 权限。

系统显示如下，则 mysql 系统库重装成功。

Installing MySQL system table...

OK

Filling help table...

OK

rm -rf mysql

mysql_install_db --user=mysql --datadir=/home/mysql/

修改文件属主。

chown -R mysql:mysql /home/mysql/

启动 mysqld 进程。

mysqld_safe --defaults-file=/home/mysql/backup-my.cnf &

使用客户端登录数据库。

mysql –u root –p

验证数据库是否完整。

系统显示入选，则数据库恢复成功。

+--------------------+

| Database           |

+--------------------+

| information_schema |

| db0dz1rv11f44yg2   |

| mysql              |

| performance_schema |

| test               |

+--------------------+

show databases

最近居然被 MySQL 主从同步的问题坑了, 简直丢尽了老司机的脸, 总结一下.

问题很简单, 一个业务由于 MySQL 主从同步延迟导致读取的数据有问题. 问题解决了, 但如何在 AWS RDS 中获取 MySQL 的延迟信息呢? 非 AWS RDS 的传统 MySQL 中, 可以直接连到 server 通过 SHOW SLAVE STATUS 获取延迟信息.

RDS 呢?

AWS 中大多数(我也不确定是不是所有服务)都接入了 Cloudwatch. Cloudwatch 的好处就是可以作为一个中间层抽象, 将不同系统的数据抽象成一个模型, 统一通过 Cloudwatch API 访问. 就拿主从延迟来说, MySQL/MariaDB 和 PostgeSQL 的计算方法显然是不一样的:

因此, 只要通过 Cloudwatch API 获取 ReplicaLag 这个 metric 的值就可以判断主从同步延迟, 不管是哪种 DB

看上去挺简单的 API, 还是需要"进城手册", 避免挠头:

由于 Cloudwatch 支持的最细颗粒度的 metric 是1分钟, 因此仅仅获取前一分钟的数据可能会有 Cloudwatch 数据还未抓取到的问题.

建议是获取前一段时间(比如10分钟)的数据, 确保前10分钟的 ReplicaLag 都为0(或者小于一个可以接受的值), 则认为现在的状态是满足数据需求的.

MySQL 主从同步从入行就知道是需要重点关注的, 结果还是忽略了一下就掉坑里了. AWS Cloudwatch 也支持根据 ReplicaLag 的值直接告警的, 建议一定要设置一个.

---