GMO NIKKOのT.Kです。
この記事の内容は、執筆時点で作業日から経過しているので情報が古くなっている可能性があります。MariaDBのアップグレードは環境によって異なるので、必ずバックアップを取って自己責任で行ってください。万が一トラブルが発生しても、責任は負いかねますのでご了承ください。
バージョン選定
タイトルに「最新バージョン」とありますが、実はLTS版を使いたかったので、MariaDB Serverの11.4を選びました。
手順の検討
Galera Cluster構成だったので、最初はローリングアップデートを考えました。しかし、かなり古いバージョンから一気に最新にするのは難しくて、いくつか中間バージョンを経由しないといけませんでした。各バージョンごとに動作検証をするのは手間がかかるんですよね。
幸い、MariaDBは古いバージョンから新しいバージョンへのレプリケーションがスムーズにできるように設計されています。なので、今回はレプリケーションを使って、新しい環境を構築しました。
新しい環境の構築
データのコピーには MariaDB-backup を使用しました。ネットの情報によると、バックアップのデータの一貫性チェック（mariabackup –prepare）は新しいサーバー上で実行するのが一般的なようです。しかし今回は、バージョンが離れすぎていたためか、新しいサーバーで実行するとエラーになってしまいました。そこで、古いサーバーでデータの一貫性のチェックを行いました。
次に、バックアップ内の xtrabackup_info ファイルからポジション情報を取得して、CHANGE MASTER TO コマンドでそのポジション情報を設定し、無事にレプリケーションを開始することができました。
切り戻し検証
アップグレード後に問題が起きたら、元のバージョンに戻す可能性もありますよね。そのとき、新しくなったデータを古い環境にも反映させる必要があります。しかし、新しいバージョンから古いバージョンへのレプリケーションは保証されていなかったので、実際に環境を作って動作検証を行いました。
動作検証時に mysql.gtid_slave_pos が原因でレプリケーションが止まることがあったため、replicate_ignore_table に設定して回避しました。
もしレプリケーションがうまく動作しなかった場合は、自分でbinlogを抽出して反映させる必要がありました。なので、レプリケーションがちゃんと動いてくれて本当に助かりました。
- エラーメッセージ
1Last_Error: Error during XID COMMIT: failed to update GTID state in mysql.gtid_slave_pos: 1062: Duplicate entry '0-2' for key 'PRIMARY' - replicate_ignore_tableの設定
123[mariadb]...replicate_ignore_table=mysql.gtid_slave_pos
切り替え
ダウンタイムが発生しますが、全アプリケーションを一旦停止して、データの同期が完了するのを待ちました。その後、順次接続先を新しい環境に変更して、アプリケーションを再開しました。
おわりに
一般的なレプリケーション構築の手順はネット上にたくさんあるので、ここではつまずいたところだけ簡単に書きました。少しでも参考になれば幸いです。
