Mariabackupによるバックアップ/リストアでMariaDBレプリケーション環境構築

MAGAZINE

ルーターマガジン

Mariabackupによるバックアップ/リストアでMariaDBレプリケーション環境構築

2022.06.16

MariaDB（MySQL）でレプリケーション環境を構成していると、ふとした拍子にSlaveへの同期がエラーで停止してしまうことがたびたび起こります。都度、同期の原因を調査・解消してレプリケーション再開を試みますが、あまりにもデータの差が大きい、どのポジションから同期が取れていないかの中断地点の特定が難しいという場合は、やむを得ずMasterからフルバックアップを取得しSlave環境を再構築することもあります。

が、こういう時にDBのデータ量が大きいとmysqldumpによるバックアップリストアではSlaveの再構築に時間を要してしまい（特にリストアが長い(T_T)）、Master-Slaveの片系で稼働する不安定な時間が長期化してしまいます。「残った片系も停止してしまったら、ついにDBが全面停止してしまう…」と思うと、不安で、不安で、精神衛生上も良くないので一刻も早くMaster-Slave構成を復旧したいところです。

ということで、こういうときに非常に嬉しい、mysqldumpよりも高速にバックアップ/リストアを行うことができるMariabackupを使ってレプリケーションSlaveを再構築する手順をご紹介したいと思います。

Mariabackupとmysqldumpのバックアップ/リストア時間・データサイズ比較

まず最初に、Mariabackupのメリット・デメリットを考えてみたいと思いますが、一言でいうと「バックアップ/リストアが早いが、バックアップファイル容量が大きい」ということが言えそうです。以下、バックアップ／リストア時間を比較してみました。

▼mysqldumpのバックアップ/リストア時間・データサイズ

データベースはMariaDB
データファイルサイズ700GB前後
サーバースペックは CPU：2GHzくらい x 4core / メモリ：32GB / ストレージ：フラッシュディスク
バックアップ中も秒間1レコード程度の新規レコードが作成される

項目	mysqldump	Mariabackup(非圧縮）	Mariabackup(圧縮）
バックアップ時間	約2時間	約1時間	約2時間
圧縮展開(--decompress)時間	--	--	約30分
prepare時間	--	約3分	約3分
リストア時間	約20時間	1秒以下	1秒以下
バックアップデータサイズ	約460GB	約700GB	約270GB

mysqldumpとMariabackupの比較結果としては、リストア時間で非常に大きな差が生まれました。また、Mariabackupを利用する場合も圧縮・非圧縮により圧縮・展開分の時間がかかりますので、データサイズとのトレードオフを想定して、利用用途によって使い分けるべきかと思います。

Mariabackupによるレプリケーション用バックアップ/リストア手順

それではMariabackupによるMariaDBのバックアップ・リストア（かつレプリケーションSlave環境構築）の手順を確認していきます。ちなみに、MariaDB公式の下記手順を踏襲したうえで、行間を補足した手順になります。基本的な手順は公式準拠になりますのでご安心ください。

Setting up a Replication Slave with Mariabackup

Mariabackup環境構築

Mariabackupとqpressをインストール

○Mariabackup

$ yum install MariaDB-backup

○qpress

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install qpress

Mariabackupによるバックアップ

Masterでバックアップ作成

まずはレプリケーションMasterでMariabackupによるバックアップを作成します。後続の手順でレプリケーションスレーブに設定するGTID情報が必要となりますので、--slave-infoオプションを付与してSlaveサーバーをセットアップするために必要な情報をキャプチャーします。

＃ mariabackup --backup --slave-info --compress -u root --target-dir=/extdisk/work/backup_20220615
〜〜略〜〜
[00] 2021-04-22 18:23:48 Compressing xtrabackup_info
[00] 2021-04-22 18:23:48         ...done
[00] 2021-04-22 18:23:48 Redo log (from LSN 4389415490814 to 4389512449444) was copied.
[00] 2021-04-22 18:23:48 completed OK!

▼rsyncコマンドでMasterのバックアップデータをSlaveに転送

rsyncコマンドやSCPコマンドなどでMasterサーバーのバックアップデータをSlaveサーバーに転送します。

＃ rsync -avP /extdisk/work/backup_20220615/ user@slave_server:/extdisk/work/backup_20220615

Mariabackupによるリストア

▼Slave DBのリストア準備

SlaveにMariabackupのデータを転送できたらリストアを行います。まず、既存のDBのデータファイルがデータディレクトリに残っている場合は削除しておきます。

＃ cat /etc/my.cnf.d/server.cnf | grep datadir
datadir = /extdisk/mysql

＃ rm -rf /extdisk/mysql/

▼圧縮したバックアップデータの展開

バックアップ時に--compressオプションを付与し圧縮を行っていましたので、まずはバックアップファイル群の展開が必要となります。

＃ mariabackup --decompress --remove-original --target-dir=/extdisk/work/backup_20220615/

▼バックアップデータの一貫性確認

prepare（準備）を行い、バックアップ作業中に更新されたレコード情報の反映やデータの不整合のチェックなどを行います。prepareはリストア前に必ず行ってください。

＃ mariabackup --prepare --target-dir=/extdisk/work/backup_20220615/

▼Slaveのリストア

リストアを実行します。通常のリストアはバックアップファイルを保持した状態でMariaDBデータディレクトリにファイルコピーする形となり、データファイル（バックアップファイル）サイズのほぼ2倍のストレージ容量が必要となります。そこで--move-backオプションをつけるとバックアップファイルをデータディレクトリに移動してリストアを行ってくれるため最小限のストレージ量でリストアを行うことができます。

＃ mariabackup --move-back --target-dir=/extdisk/work/backup_20220615/

また、必要に応じ、リストア後にデータディレクトリの所有者・グループをmysqlユーザーに変更してください。

＃ chown -R mysql. /extdisk/mysql

レプリケーション復旧

下記操作を行いSlaveサーバーをレプリケーションスレーブとして稼働開始します。

▼レプリケーション開始前の確認

MariaDBを一度起動し、Masterサーバーと同様のユーザーが存在するかを確認します。特にSlaveでレプリケーションの同期処理を行うユーザーが存在するかを確認してください。MaxScaleなどでクラスタリングを行っている場合はMaxScale用のユーザーなども存在しているか確認します。

＃ mysql -uroot

MariaDB [(none)]> select Host, User, Password from mysql.user;
+---------------+----------------+-------------------------------------------+
| Host          | User           | Password                                  |
+---------------+----------------+-------------------------------------------+
　　　　　　　　　　　　　　　〜〜中略〜〜
| %             | repl           | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX     |
+---------------+----------------+-------------------------------------------+

▼レプリケーション設定実施

レプリケーションの開始地点を確認するため、バックアップファイル群に含まれるxtrabackup_binlog_infoに記載されているGTIDを確認します。下記例では「0-1-157137023」がGTIDになります。

＃ cat xtrabackup_binlog_info
replication-log.002615  225390408       0-1-157137023

上記で確認したGTIDをレプリケーションSlaveに設定します。

＃ mysql -uroot


MariaDB [(none)]> SET GLOBAL gtid_slave_pos = "0-1-157137023";
Query OK, 0 rows affected (0.030 sec)

MariaDB [adcrawl]> show global variables like '%gtid%';
+-------------------------+---------------+
| Variable_name           | Value         |
+-------------------------+---------------+
| gtid_binlog_pos         |               |
| gtid_binlog_state       |               |
| gtid_cleanup_batch_size | 64            |
| gtid_current_pos        | 0-1-157137023 |
| gtid_domain_id          | 0             |
| gtid_ignore_duplicates  | OFF           |
| gtid_pos_auto_engines   |               |
| gtid_slave_pos          | 0-1-157137023 |
| gtid_strict_mode        | OFF           |
| wsrep_gtid_domain_id    | 0             |
| wsrep_gtid_mode         | OFF           |
+-------------------------+---------------+
11 rows in set (0.001 sec)

レプリケーションMasterへの接続情報を設定します。

MariaDB [adcrawl]> CHANGE MASTER TO MASTER_HOST = '10.XXX.XXX.1', MASTER_USER = 'repluser', MASTER_PASSWORD = 'replpw', MASTER_USE_GTID = slave_pos;
Query OK, 0 rows affected (0.011 sec)

ここまででレプリケーションSlaveの設定は完了です。スレーブステータスを確認するとMasterの情報が設定され、Slave_XX_RunningはNoの状態になっているかと思います。

MariaDB [adcrawl]> show slave status\G;
*************************** 1. row ***************************
                Slave_IO_State:
                   Master_Host: 10.XXX.XXX.1
                   Master_User: repl
                   Master_Port: XXXXX
                 Connect_Retry: 60
               Master_Log_File:
           Read_Master_Log_Pos: 4
                Relay_Log_File: mariadb-relay-bin.000001
                 Relay_Log_Pos: 4
         Relay_Master_Log_File:
              Slave_IO_Running: No
             Slave_SQL_Running: No
〜〜中略〜〜
1 row in set (0.000 sec)

ERROR: No query specified

▼レプリケーション再開

あとはスレーブプロセスをスタートさせてあげればレプリケーションが開始されるかと思います。ステータスを確認してSlave_XX_RunningはYesの状態になっていること、Gtid_IO_PosのGTIDの値が進んでいくことなどを確認してください。当然テーブルのデータを確認しながらMasterとSlaveでレコードの同期が取られていることの確認も必要ですね。

＃ mysql -uroot

MariaDB [(none)]> start slave;

MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
                Slave_IO_State: Waiting for master to send event
                   Master_Host: 10.XXX.XXX.1
                   Master_User: repl
                   Master_Port: XXXXX
                 Connect_Retry: 60
               Master_Log_File: replication-log.002616
           Read_Master_Log_Pos: 1279868777
                Relay_Log_File: mariadb-relay-bin.000002
                 Relay_Log_Pos: 2656065
         Relay_Master_Log_File: replication-log.002615
              Slave_IO_Running: Yes
             Slave_SQL_Running: Yes
〜〜中略〜〜
                    Using_Gtid: Slave_Pos
                   Gtid_IO_Pos: 0-1-157522214
       Replicate_Do_Domain_Ids:
   Replicate_Ignore_Domain_Ids:
                 Parallel_Mode: conservative
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: Closing tables
              Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 1416
1 row in set (0.000 sec)

まとめ

弊社も自社サービスのアドクロール（国内最大規模のインターネット広告データベース）をはじめ、スクレイピング（クローリング）技術により収集したビッグデータを安定的に保守運用するため、日夜インフラ面の安定化の努力を行っています。

DBの冗長化は有望な選択肢になりますが、冒頭に上げた通り不足の事態に方系運用となることはどうしても避けられません。そんな時の早期復旧方法として、ストレージ容量に余裕があるのであればMariabackupはバックアップ・リストア速度の面でとても有効な選択肢になりますので、ぜひいざという時の参考になればと思います。（というより、いざと言う時の前にぜひ一度お試し下さい！）

Pocket

CONTACT

お問い合わせ・ご依頼はこちらから