Posted inデータベース

データベースレプリケーション：マスター・スレーブとマルチマスターのセットアップを解説

Database tutorial - IT technology blog
Database tutorial - IT technology blog

午前2時のページャーコール：データベースが停止したとき

午前2時。恐れていたページャーが鳴り響き、深い眠りから引きずり出されます。CRITICAL - Production Database Offlineというアラートを見て、心臓が凍りつきます。あなたは慌ててノートパソコンに飛びつき、キーボードを叩きながら問題の診断を試みます。ユーザーは500エラーを受け取り、トランザクションは失敗し、刻一刻とビジネスは損失を被っています。単一障害点がアプリケーション全体をダウンさせる、あの胃が締め付けられるような感覚を、誰もが経験したことがあるのではないでしょうか？

1時間の必死のトラブルシューティングの後、なんとかサービスを再起動できました。しかし、損害はすでに発生しています。事後検証で明らかになったのは、厳しい現実でした。単一のモノリシックなデータベースサーバーがすべての処理を担っていたのです。ハードウェアの不具合、不正なクエリ、予期せぬトラフィックの急増など、何らかの原因でそれが停止したとき、頼るべきものは何もありませんでした。結果として、システム全体が停止してしまったのです。

根本原因分析：単一障害点症候群

あの午前2時のインシデントは単なる不運ではありませんでした。それは根本的なアーキテクチャの弱さの症状でした。すべての操作を単一のデータベースサーバーに依存することは、一本の支持梁で家を建てるようなものです。その梁が壊れるまでは機能しますが、壊れるとすべてが崩壊します。私たちが直面した主な問題は、以下の欠如でした。

  • 高可用性 (HA): プライマリデータベースのような重要なコンポーネントがオフラインになっても、システムが機能し続ける能力。
  • 災害復旧 (DR): データセンター全体の障害のような大規模なインシデントが発生した場合に、データとサービスを復旧するための堅牢な戦略。
  • スケーラビリティ: プライマリサーバーに過負荷をかけたり、パフォーマンスを低下させたりすることなく、特に読み取りトラフィックの増加に対応できる能力。

これらの保護策がなければ、データベースは脆弱です。レプリケーションは、これらのシナリオに対する主要な防御策として機能し、常に複数の最新のデータコピーを用意して、いつでも引き継ぎできるようにします。

ソリューション比較：マスター・スレーブ vs. マルチマスターレプリケーション

データベースレプリケーションの本質は、あるデータベースサーバーから1つ以上の他のサーバーにデータをコピーすることです。この基本的な技術は、可用性、災害復旧、および読み取りスケーラビリティを大幅に向上させます。ここでは、その主要な2つのタイプを探ってみましょう。

マスター・スレーブレプリケーション：主力選手

これはおそらく最も一般的なレプリケーション設定でしょう。多くのユースケースにおいて、シンプルかつ非常に効果的なソリューションです。

仕組み：

この設定では、1つのサーバーがプライマリ、つまりマスターとして機能します。このマスターサーバーが、すべての書き込み操作（挿入、更新、削除）を処理します。その後、これらの変更を非同期的に（パフォーマンス上の理由から同期はあまり一般的ではありませんが、場合によっては同期的に）1つ以上の他のサーバー、すなわちスレーブに送信します。これらのスレーブは通常、読み取り操作を処理します。新聞に例えると、マスターは記事を書く編集者であり、スレーブは読者にコピーを配布する印刷機のようなものです。

メリット：

  • 読み取りスケーリング: 読み取りクエリを複数のスレーブサーバーに分散させることで、マスターの負荷を大幅に軽減できます。これにより、読み取り集中型のワークロードにおいて、アプリケーション全体のパフォーマンスを2～5倍向上させることができます。
  • 高可用性/災害復旧: マスターサーバーが故障した場合、スレーブの1つを新しいマスターに昇格させることができ、ダウンタイムをわずか数秒または数分に抑えることができます。これは、あの午前2時のインシデントから迅速に復旧するために非常に重要です。
  • レポートと分析: トランザクション処理を行うマスターのパフォーマンスに影響を与えることなく、負荷の高いリソースを消費する分析クエリを実行したり、スレーブサーバー上でレポートを生成したりできます。

制限事項：

  • 単一書き込み点: マスターは書き込みにおける単一障害点であることに変わりはありません。マスターがダウンすると、新しいマスターが正常に昇格されるまで、新しい書き込み操作は停止します。
  • フェイルオーバーの複雑さ: スレーブを昇格させることは可能ですが、特に自動フェイルオーバーのプロセスは、正しく設定するのが複雑になることがあります。切り替え時のデータの一貫性を確保するには、慎重な計画が必要です。
  • レプリケーション遅延: 非同期レプリケーションでは、マスターとスレーブの間にわずかな遅延（「ラグ」）が発生することがあり、負荷が高い場合は数ミリ秒から数秒に及ぶことがあります。これは、スレーブが常に最新のデータを持っているとは限らないことを意味します。書き込み直後の読み取りの一貫性を必要とするアプリケーションにとっては懸念事項となる可能性があります。

実践例：MySQLマスター・スレーブレプリケーションのセットアップ

MySQLの簡単な例を見てみましょう。db-master.yourdomain.comとdb-slave.yourdomain.comという2つのサーバーがあるとします。

1. マスターの構成 (db-master.yourdomain.com)

MySQLの設定ファイル（例: /etc/mysql/my.cnf または /etc/my.cnf）を編集します。


# マスター設定
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_do_db = your_database_name # オプション: 特定のデータベースのみをレプリケートする
# セミシンクロナスレプリケーションの場合。マスターは、コミットする前に少なくとも1つのスレーブがbinlogイベントの受信を承認するまで待機します。
# rpl_semi_sync_master_enabled = 1
# rpl_semi_sync_master_timeout = 5000 # ミリ秒

マスターでMySQLを再起動します。


sudo systemctl restart mysql

次に、レプリケーションユーザーを作成し、マスターのステータスを取得します。


mysql -u root -p

# レプリケーションユーザーを作成
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'your_secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

# テーブルをロックし、マスターのステータスを取得します（一貫性のあるスナップショットのために、メンテナンス期間中またはトラフィックが少ないときに実行してください）
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
# ファイル名と位置をメモします（例: mysql-bin.000001 および 123）

# ステータス取得後、テーブルのロックを解除
UNLOCK TABLES;
EXIT;
2. スレーブの構成 (db-slave.yourdomain.com)

MySQLの設定ファイルを編集します。


# スレーブ設定
[mysqld]
server-id = 2
relay_log = mysql-relay-bin
read_only = 1 # オプションですが、スレーブへの誤った書き込みを防ぐために強く推奨されます

スレーブでMySQLを再起動します。


sudo systemctl restart mysql

次に、以前にメモした情報を使用して、スレーブをマスターに接続します。


mysql -u root -p

CHANGE MASTER TO
  MASTER_HOST='db-master.yourdomain.com',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='your_secure_password',
  MASTER_LOG_FILE='mysql-bin.000001', -- SHOW MASTER STATUSから取得したファイル名を使用
  MASTER_LOG_POS=123;                -- SHOW MASTER STATUSから取得した位置を使用

START SLAVE;

SHOW SLAVE STATUS\G
EXIT;

スレーブでSHOW SLAVE STATUS\Gを確認します。Slave_IO_Running: YesとSlave_SQL_Running: Yes、そしてSeconds_Behind_Master: 0（またはごく小さな数値で、ラグが最小限であることを示す）が表示されていることを確認してください。

マルチマスターレプリケーション：分散型パワーハウス

マルチマスターレプリケーションは、これらのメリットをさらに高め、より高い可用性と書き込みのスケーリング能力を提供します。これは、データ冗長性に対するより高度なアプローチです。

仕組み：

マスター・スレーブでは1つのサーバーのみが書き込みを受け入れるのに対し、マルチマスター設定では、参加するすべてのサーバーが書き込み操作を受け入れることができます。いずれかのマスターで行われた変更は、自動的に他のすべてのマスターに伝播されます。これにより、どのノードでも読み取りと書き込みの両方を処理できる、真のアクティブ・アクティブ環境が実現します。

メリット：

  • 単一障害点なし（書き込みの場合）: いずれかのマスターがダウンしても、他のマスターはシームレスに書き込み操作を継続できます。これは、極端な稼働時間を要求するアプリケーションにとって大きな利点です。
  • 書き込みスケーラビリティの向上: 書き込み負荷を複数のサーバーに分散させる可能性があり、毎秒数千のトランザクションを処理する高スループットアプリケーションにとって有益です。
  • 地理的分散: 堅牢な災害復旧のために、異なるデータセンターにマスターを設定できます。これにより、様々な地域のユーザーが最寄りのデータベースインスタンスにアクセスする際のレイテンシも低減されます。

制限事項：

  • 競合解決: これが最大の課題です。同じデータが2つの異なるマスターで同時に変更された場合、何が起こるでしょうか？例えば、2人のユーザーが異なるマスターで同じ在庫数を10から9、10から8に更新した場合です。データの一貫性を維持するためには、「最終書き込み者優先 (last-writer-wins)」、タイムスタンプベースのアプローチ、またはカスタムアプリケーションロジックのような洗練された競合解決戦略が必要です。これにより、システムにかなりの複雑さが加わります。
  • ネットワークトラフィックの増加: すべてのマスター間でより多くのデータを同期する必要があり、特に書き込み量が多い場合には、ネットワークオーバーヘッドが大幅に増加する可能性があります。
  • 複雑さの増大: セットアップ、管理、トラブルシューティングは、マスター・スレーブよりもはるかに複雑です。分散合意と一貫性モデルを扱うことになり、深い専門知識が必要です。

概念的な例：PostgreSQL論理レプリケーション（簡略化されたマルチマスターの考え方）

自動競合解決機能を備えた真のマルチマスターは、通常、特殊なソリューション（MySQLのGalera Clusterや特定のPostgreSQL拡張など）によって処理されますが、PostgreSQLの論理レプリケーションは、双方向のマルチマスター設定の一種を実現するように構成できます。ただし、アプリケーションによっては手動での競合処理が必要になる場合があります。

マスター1にて：


CREATE PUBLICATION my_publication FOR TABLE my_table;

マスター2にて：


CREATE PUBLICATION my_publication FOR TABLE my_table;

次に、各マスターは互いのパブリケーションを購読します。マスター1にて：


CREATE SUBSCRIPTION my_subscription_to_m2
  CONNECTION 'host=master2_ip port=5432 user=repl_user password=your_password dbname=your_db'
  PUBLICATION my_publication;

マスター2にて：


CREATE SUBSCRIPTION my_subscription_to_m1
  CONNECTION 'host=master1_ip port=5432 user=repl_user password=your_password dbname=your_db'
  PUBLICATION my_publication;

これにより、変更が双方向に流れるパスが作成されます。ただし、書き込み競合を防ぐため、または競合が適切に解決されるように、シーケンス、トリガー、またはアプリケーションロジックを慎重に管理する必要があります。

最適なアプローチの選択：将来の午前2時コールを防ぐために

次のアーキテクチャ設計に直面したとき、どのようにして適切なレプリケーション戦略を選択すればよいでしょうか？決定は、特定のニーズ、アプリケーションのダウンタイム許容度、およびチームの運用能力に左右されます。

マスター・スレーブレプリケーションを使用する場合：

  • ほとんどの一般的なWebアプリケーション: 読み取りスケーリングが主な関心事であり、フェイルオーバー時の書き込みダウンタイムが一時的（例：数分）であれば許容できる場合。
  • 明確なプライマリストラテジー: すべての書き込みに対して明確に定義されたプライマリデータベースと、堅牢な災害復旧戦略が必要な場合。
  • よりシンプルなセットアップ: 運用上のオーバーヘッドと複雑さを最小限に抑えたい場合、マスター・スレーブは通常、実装と管理が容易です。

マルチマスターレプリケーションを使用する場合：

  • 極めて高い書き込み可用性: サーバーが故障しても、書き込みに対するダウンタイムがほぼゼロであることを要求するアプリケーション向け。重要な金融システムやリアルタイムゲームプラットフォームなどを想定してください。
  • 分散書き込み負荷: グローバルなユーザーにサービスを提供するために、複数のサーバー（異なる地理的地域にある可能性も含む）に書き込み操作を分散させる必要がある場合。
  • ハイエンドのエンタープライズシステム: 稼働時間とデータ分散に対する厳格なビジネス要件によって、競合解決の管理に伴う複雑さとオーバーヘッドが正当化される場合。

マルチマスターでは、かなりのアーキテクチャ上および運用上の複雑さが伴うことを覚悟してください。これは万能薬ではなく、多くの場合、アプリケーションの一貫性要件と、選択したデータベースが競合をどのように処理するかについての深い理解が必要です。これは、しばしばアプリケーションレベルでの設計上の考慮事項を必要とします。

データベースレプリケーションを扱う際、レプリカの初期シードや分析レポート用のデータ準備といったタスクは一般的です。特にCSVファイルをJSONに変換してインポートするような迅速なデータ変換には、私は頻繁にtoolcraft.app/ja/tools/data/csv-to-jsonを利用しています。

これはブラウザで直接動作するため、機密データが自分のマシンから離れることがないのが素晴らしい点です。小さなユーティリティですが、新しいスレーブや初期データシードのためにテストデータや設定データを素早く準備する必要があるときに、本当に助けになります。

結論として、データベースレプリケーションは、堅牢で高可用性なシステムの基盤を形成します。これは、深夜のパニックコールを防ぎ、予期せぬ事態が発生してもサービスが稼働し続けることを保証するものです。フェイルオーバー手順は常に厳密にテストしてください。災害復旧計画に穴があることを午前2時に発見するまで待ってはいけません！

Share:
Tags: