xbcloud

www.percona.com

xtrabackup (innobackupex) と S3 (minio) とか GCS と組み合わせるときに、公式純正の CLI よりも速いしリソースも少なく使えるらしい。
www.percona.com

xbcloud を使う理由

上であげた理由もそうだけど S3 に上げる容量が 50GB を超えると、aws s3 cp だけでは限界がくる。

50GB を超えれない

https://docs.aws.amazon.com/AmazonS3/latest/dev/qfacts.html

Multipart Upload Limits が5 MB（デフォルト） ごとに最大 10,000 個までということでデフォルトのままだと１ファイルで最大 50GB までしかあげれない。
ただ、aws configure set default.s3.multipart_chunksize 16MB で設定すればあげれるとは思う（確かめてない）

それに対して xbcloud は 10 MB ごとに、ファイルを分割してストレージに投げる（10 MB ごとにファイルができる）のでここらへんは気にしなくて良くなる。

xbcloud はインストールが手軽

aws cli は pip 入れて、pip install が必要だけど、xbcloud は percona-xtrabackup を入れれば勝手に入る。
何が嬉しいかって、Ansible で管理するときにだいぶ楽になる。

フルバックアップ

# xtrabackup --backup --stream=xbstream --target-dir=/tmp --user=root --slave-info --compress | xbcloud put --storage=s3 --s3-endpoint='s3.ap-northeast-1.amazonaws.com' --s3-access-key='' --s3-secret-key=’' --s3-bucket='db' --parallel=20 $(date -I)-full_backup

compress + xbstream
xbstream を使うと、parallel が使える

リストア

まずは取得
# xbcloud get s3://db/2020-01-17-full_backup --storage=s3 --s3-endpoint=s3.ap-northeast-1.amazonaws.com --s3-access-key='' --s3-secret-key='' --parallel=4 2>download.log | xbstream -x -C restore --parallel=4
compress したから decompress
# xtrabackup --decompress --target-dir=/mnt/data/restore --remove-original
ここからはいつもどおり
# xtrabackup --prepare --target-dir=/mnt/data/restore
# innobackupex ---move-back /mnt/data/restore
# mv /mnt/data/restore /mnt/data/mysql
# chown -R mysql: /mnt/data/mysql
# systemctl start mysql
gitd_purge の値を取得しとく
# cat xtrabackup_slave_info
# mysql -uroot
mysql> SET GLOBAL gtid_purged='e9043a49-18c3-11ea-89ae-fa163e4dcf94:1-183923308';
mysql> change master to 省略, mysql_auto_position=1;
mysql> start slave;

デメリット

–storage-class が使えないのでライフサイクルで回さないと行けない。
フルバックアップも、バイナリログも必要になるときはそうそうないので、できれば ONEZONE_IA を使いたい。