有木有 DBA 大佬，想求教一下数据库云备份的方案

可以快速恢复至半小时前的状态,说明对数据一致性要求不高,可以考虑
1. 跨区在部署一个 slave,不同区域同时挂的概率相对是很低很低的, 当同一个区挂了,可以直接切到另一个区,数据延迟也不会高.
2. 通过 xtrabackup 进行每天的全量备份, 然后将备份拷贝到另一个地方, binlog 可以根据实际情况进行备份走.
3. 直接上云实例,一样跨区部署

yekern

2023-11-15 10:00:18 +08:00

xtrabackup 全量备份以后,每几个小时或者每天走增量备份.

```
#!/bin/bash

DATA_DIR="/opt/mysql/data"

BACKUP_DIR="/data/backup"

OLD_DIR=`cat /data/backup/log/mysql-last-backup.log`

NEW_DIR=`date +%F`

MYSQL_DATABASE_HOST="地址"

MYSQL_DATABASE_USERNAME="用户名"

MYSQL_DATABASE_PASSWORD="密码"

MYSQL_DATABASE_PORT=3306

if [[ ! -d ${BACKUP_DIR}/base ]];then

echo "还未全量备份"

exit 1

fi

/usr/bin/xtrabackup --defaults-file=/opt/mysql/conf/my.cnf --backup --compress=lz4 --datadir=${DATA_DIR} --incremental-basedir=${BACKUP_DIR}/${OLD_DIR} --target-dir=${BACKUP_DIR}/${NEW_DIR} --user=${MYSQL_DATABASE_USERNAME} --password=${MYSQL_DATABASE_PASSWORD} --port=${MYSQL_DATABASE_PORT} --host=${MYSQL_DATABASE_HOST} --no-server-version-check --apply-log-only &> /data/backup/log/mysql-last-backup.log

tail -n 1 /data/backup/log/mysql-last-backup.log | grep 'completed OK!'

if [[ $? -eq 0 ]];then

echo "${NEW_DIR}" > /data/backup/log/mysql-last-backup.log

else

echo "备份失败"
echo "${OLD_DIR}" > /data/backup/log/mysql-last-backup.log

exit 1

fi
```

clacf1

2023-11-15 10:08:42 +08:00

@SpMozzi 我们有次，是因为代码问题，切了备机以后，备机也被整挂了。主从这种模式，没法低于来自代码 bug 导致的问题。这个 xtrabackup 的备份效率高吗？和 mysqldump 比较起来呢？因为涉及到快速恢复，最好可以分库备份。

chuckzhou

2023-11-15 10:57:33 +08:00

这么大数据量想要迅速恢复，只能用 btrfs 的快照，zfs 应该也可以。
采样主从方式，在从服务器上隔半个小时就建立一次快照。
出问题了就恢复最近一次的快照，然后把从切为主。
如果你网卡是 10G 以上的，用 xtrabackup 也行，恢复 1T 数据估计得 20 分钟。

joyhub2140

2023-11-15 11:23:26 +08:00

只有快照才能满足楼主需求了，不用运维去做把，我记得云厂商都有快照功能，根据快照的大小进行计费。只对数据库的的云盘打快照就行了。

jixiangqd

2023-11-15 11:24:14 +08:00

云上数据库不建议搞这么大，建议拆成多个库，使用中间件访问。
比如阿里云以前的 DRDS ，现在的 Polar-X 。

如果非要搞这么大，建议不要用开源，用云各家厂商搞的存算分离架构数据库恢复会快一些

Worldispow

2023-11-15 11:26:34 +08:00

xtrabackup 我记得是要登录服务器操作的，云数据库不具备操作条件，最好的办法是购买云厂商的数据备份服务

buchikoma

2023-11-15 11:30:40 +08:00

数据量大，还有时间点恢复的需求，为啥不直接用 rds 实例

tool2d

2023-11-15 11:34:39 +08:00

你那么大的数据量，用 binlog 也不是那么靠谱，太慢了。

最好就是二进制数据和文本数据分离，严重怀疑 1tb 直接把图片之类的保存进去了。应该学 github ，大文件走专门的通道，不要图省事用 blob ，和文本数据库混合在一起。

wps353

2023-11-15 11:53:01 +08:00

应该招个 DBA 来解决问题。/dog

Itesting

2023-11-15 13:06:01 +08:00

如果快速恢复到 X 小时前的话，可以设置配置一个 slave 节点，配置：CHANGE MASTER TO MASTER_DELAY = N;
，比如：30 分钟，180 分钟，这样这个实例就是历史的状态，如果线上 DB 出问题可以马上恢复。相关参数官网说明链接： https://dev.mysql.com/doc/refman/5.7/en/replication-delayed.html
注意：上述方案按照钱来换时间，即使开启这个，也要开启相应的全量备份。同时设置的时间要把握好，如果决策慢了，这个 slave 节点的数据会和线上一致也无法提供服务了。

0x1111

2023-11-15 13:13:06 +08:00

1 ，还可以考虑主从外，再加一个跨区的延时 slave ，指定同步延时 1 小时或 1 天这种思路，实时业务真出问题，能有一个延时数据可以快速提供服务
2 ，xtrabackup+binlog ，这么大的数据量，备份需要时间，恢复也是需要很久的，这种可能磁盘快照会更合适，云服务快照，lvs 快照
3 ，单实例这么大的数据量，可运维性非常不友好，还是核心存储的话，真的建议治理下，看看怎么拆分。