MySQLのレプリケーション機能では、複数のサーバーにデータを保持することができます。
レプリケーション方式には大きく2種類あり、
- 性能を重視した非同期レプリケーション
- 安全性を重視した準同期レプリケーション
に分かれています。今回はそれぞれの違いについて詳しく解説します。
MySQL のレプリケーションとは
MySQL は「レプリケーション」と呼ばれる機能を備えています。
レプリケーションを有効化すると、複数のサーバーで同一データを保持できます。
レプリケーションを使用する主な目的としては以下の3点です。
- サーバー故障時に備えた冗長性確保
- データベースの負荷分散とそれに伴う性能向上
- 用途別にサーバーを振り分けるなどの役割分担
レプリケーションを行う場合、いずれか1台が「マスター」として親の役割を果たします。
残りのサーバーは「スレーブ」と呼ばれ、マスターのデータが複製されます。
なお、データベースを書き換える際は必ずマスターで処理しなくてはいけません。
スレーブは読み取り専用のデータベースとして利用でき、
読み取りアクセスが多いデータベースでは、スレーブ追加により負荷分散が図れます。
MySQL の準同期レプリケーションは信頼性重視
MySQL の「準同期レプリケーション」は、信頼性を重視した方式です。
マスターサーバーでデータベースを更新すると、その変更内容がスレーブにも転送されます。
スレーブが変更内容を受け取れた時点で、マスターの更新作業が完了扱いとなります。
メリットとしては、仮にマスターサーバーに障害が発生してもデータが保持される点です。
変更内容がスレーブに転送されるため、最新のデータはスレーブから救い出すことができます。
デメリットは、スレーブへの転送待ちにより処理速度が低下する点です。
ネットワーク状況によっては転送に時間がかかり、更新処理の完了が待たされる場合もあります。
以上のことから、準同期レプリケーションは、データの信頼性を重視する場合に向いています。
MySQLの非同期レプリケーションは性能重視
MySQLの「非同期レプリケーション」は、デフォルトで使用される方式です。
マスターサーバーでのデータ更新時は、即座に更新作業が完了扱いとなります。
更新完了を通知した後、変更内容をスレーブへ転送する流れとなります。
この方式のメリットは、データ更新時の性能劣化が少ないことです。
スレーブへの反映を待たずに処理が完了するため、準同期よりも高速処理が可能です。
デメリットは、マスターの障害発生時に最新の変更が残らない可能性がある点です。
スレーブへの転送前に障害が発生すると、障害直前の変更が失われることになります。
非同期レプリケーションは、高速なレスポンスが求められる場合や、
データの信頼性確保をアプリケーション側でカバーできる場合に向いています。
まとめ
MySQL の「準同期レプリケーション」と「非同期レプリケーション」を比較しました。
データの信頼性、高速なレスポンスのどちらを重視するかで方式が異なってきます。
システム構成や要求される信頼性を考慮し、適切な方式を選択しましょう。
【関連記事】
⇒ MySQL のインストール手順 (CentOS)
⇒ MySQL のインストール手順 (Ubuntu)
⇒ MySQL データベースが遅いときの調査方法
⇒ AWS の「RDS」と「EC2 + MySQL」を比較
⇒ Aurora エンドポイントの使い分けを解説