地方エンジニアの学習日記

興味ある技術の雑なメモだったりを書いてくブログ。たまに日記とガジェット紹介。

【MySQL】レプリケーションはバックアップになり得ない理由

この記事は「🎅GMOペパボエンジニア Advent Calendar 2023」の9日目です!Otelについて書こうと思っていたら完全に忘れていたのでこちらです!

本文

MySQLにはレプリケーションによって同期されたデータベースサーバを構築する機能があって高可用性や負荷分散を提供する重要な機能です。一方でレプリケーションを組んでおけば2台、3台の構成となって堅牢に見えますが実はバックアップの代替としては機能しません。その理由について書いていきます。(MySQL以外でも当てはまるものが多いと思いますがレプリケーションを有効にすると自動でバージョニングするようなシステムもあったりするのでMySQLって入れてます)

バックアップとレプリカの違い

バックアップとは、データベースの内容をコピーし保存することを指します。ファイルやアプリケーション、およびそれらを含むシステム全体をコピーしたりもします。バックアップは静止店が必要だったりするので営業時間外の深夜に一時システムを止め、毎日もしくは週に一度、バックアップをとっているケースがあったりします。MySQLではInnoDBトランザクションの分離性の特性を活かした方法でシステムを止めずに実施できたりします。

一方でレプリカはプライマリのデータベースが更新されるたびにプライマリの更新を伝搬してレプリカサーバ自身がその変更を適用することで実現しています。システムの負荷分散などを目的として利用されることもあります。

ここで重要なのはレプリカにはほぼリアルタイム(デフォルトは準同期で非同期レプリケーションMySQLではサポートしてます)で更新が起きるという点です。バックアップは方法は様々ありますが静止点をとってその時点のデータをコピーします。静止点は複数持つことができ例えば1/1 0:00と1/2 12:00時点のデータをコピーすることができます。プライマリサーバの故障時にはこのバックアップのデータから特定の時点へデータを戻すことができるのです。さらにbinlogの機能を有効化しておくことでPITRと呼ばれる特定時刻へのリストアを行うことが可能となります。1/1 10:00の時点のデータに復旧するには1/1 0:00のデータでリストアを行いそこまでの更新ログを適用することでPITRを実現します。

一方でレプリカはどうでしょうか?プライマリサーバが1/2 12:00に故障したとするとレプリカは1/ 12:00までのデータは同期がされているのでレプリカサーバをプライマリへ昇格させればサービスは継続することができます。これだけであれば特に問題となることはありません。一方で1/1 10:00にアプリケーションをデプロイして意図しないレコード削除が発生した際はどうなるでしょうか?バックアップの場合は1/1 0:00の時点に戻しそこからbinlogを適用するという流れが取れますがレプリカではアプリケーションのデプロイ後に行われたレコードの削除のクエリもレプリカサーバで実行されレコード自体が消えてしまいます。バックアップがなければ消えたレコードは今後復旧させることはMySQLの機能だけでは実現することはできません。

まとめ

レプリケーションはバックアップじゃないです。

(この記事書いてたらrsyncでバックアップ取ってるので安心!とか言っていたらsync元が消えてrsync先も消えたという失敗談を思い出した....)

おまけ2

レプリケーションはバックアップじゃないです」 - 校歌を書いてってChatGPTに言ったらいい感じに返ってきました。

[1番]
データの海を渡る航海、
レプリケーション、進め静かに。
同期する波、揺れる情報、
リアルタイムで伝わる変化。

[2番]
だけど忘れてはならない、
バックアップなしでは航海は危険。
誤った変更、消えたデータ、
過去への扉は、バックアップの中。

[3番]
プライマリの影、レプリカが追う、
でも過去の痕跡は、追えない道。
特定の時点、戻るためには、
静止の瞬間、バックアップが鍵。

[4番]
高可用性、分散の読み取り、
レプリケーションの力、輝くとき。
しかし完全性、安全のため、
バックアップがなければ、足りない答え。

[5番]
組み合わせの知恵、使い分けの美、
データを守る、二つの盾。
レプリケーション、バックアップと共に、
データの海を、安全に航海。

この校歌は、MySQLレプリケーションとバックアップの重要性をテーマにしています。レプリケーションはデータの同期とアクセシビリティを高めるために重要ですが、バックアップ無しではデータの完全性や過去への復元は保証できないことを表現しています。また、これら二つの技術は相互補完的であり、合わせて使用することでデータ管理の堅牢性を高めることを歌っています。

関連記事

dev.classmethod.jp

追記

コメントをいただきました。ちょっと考えただけでもとても楽しそうな内容なので続きは別記事に書きます!