データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計を実装者目線で解説【2026年版】

データベースのレプリケーションは、あるデータベースの更新を別のサーバーへ流し続け、同じ内容の写しを保ち続ける仕組みです。読み取りを複数台へ散らし、主系が落ちたときの切り替え先を用意する目的で使われます。難しいのは仕組みそのものではなく、どこまでの遅延と欠損を許すかという線引きの方です。この記事では、同期・準同期・非同期でコミット応答とデータ損失がどう変わるか、物理型と論理型の適用範囲、遅延の測り方と抑え方、マネージドが肩代わりする範囲までを整理しました。

まとめ：複製方式と遅延許容度から決める構成の要点

先に結論を書きます。決めるべきは製品ではなく、次の3点です。第一に、主系が失われた瞬間に何秒ぶんの更新を捨ててよいか（RPO）。第二に、複製先の遅延が何秒まで伸びても業務が壊れないか。第三に、切り替えを人が判断するのか自動で行うのか。

この3点が決まれば方式はほぼ自動的に絞られます。1件たりとも失えないなら同期か準同期を選び、書き込みの応答が延びる代償を受け入れる。数秒の欠損を許せるなら非同期で構わず、代わりに遅延の監視と、遅れたレプリカを読ませない仕組みを作る。人手が慢性的に足りない現場なら、複製と切り替えはマネージドへ寄せた方が総コストは下がります。以下、根拠を定義・方式・実装形態・遅延・マネージド・判断の順に分解します。

レプリケーションの定義とバックアップ・シャーディングとの線引き

主系から複製先へ変更ログを流し続ける複製処理の基本構造と用語

レプリケーションが行うのは、書き込みを受け付ける1台（PostgreSQLではプライマリ、MySQLではソース）で発生した変更を記録し、その記録を複製先へ転送して同じ順序で適用し直すことです。PostgreSQLならWAL（先行書き込みログ）、MySQLならバイナリログが転送の実体です。データファイルをコピーし続けるわけではありません。

呼称は近い時期に大きく変わりました。MySQLは8.0系でマスター／スレーブという語をソース／レプリカへ置き換え、8.4ではSHOW SLAVE STATUSやCHANGE MASTER TOといった旧構文自体が削除されています。運用スクリプトが古い構文のまま8.4へ上がると、その時点で動かなくなる。複製まわりの構文の棚卸しは、バージョンアップ計画の先頭へ置いてください。

誤削除や論理破損がそのまま伝播するバックアップとの決定的な違い

レプリケーションはバックアップの代わりになりません。理由は単純で、複製は「正しく行われた更新」も「間違って行われた更新」も区別せず伝えるからです。DELETEの条件を間違えて100万行消せば、その削除は数秒後に複製先でも実行されます。

守れる障害の種類が違う、と考えると整理できます。複製が守るのはサーバーやディスク、AZの故障。バックアップが守るのは人的ミスとアプリケーションのバグ、そしてランサムウェアによる暗号化です。どちらかで代替できる関係ではありません。遅延レプリカ（MySQLのSOURCE_DELAYやPostgreSQLのrecovery_min_apply_delay）を1時間ぶん遅らせて置く構成は、この弱点を部分的に埋める手当として使えます。

読み取り分散と書き込み分散で役割が分かれる複製と分割の使い分け

台数を増やす手法は複数あり、効くボトルネックがそれぞれ違います。

参照が負荷の大半を占める業務システムなら、複製先を足すだけで数年しのげます。逆に書き込みが1台の上限に張り付いている場合、レプリカを何台足しても解決しない。その段階で検討へ入るのがシャーディング（水平分割）の仕組みとシャードキー設計で、複製とは別系統の判断になります。1台のデータベースの中で表を切り、索引と保守の粒度を整えるのはパーティショニングの分割方式と絞り込み設計が扱う領域です。

同期・準同期・非同期で変わるコミット応答とデータ損失の境界線

コミット完了と判断する地点の違いが決めるRPOと書き込み遅延

3方式の差は「主系がクライアントへ完了を返す前に、どこまで複製先の応答を待つか」の一点に集約されます。

準同期が実務で選ばれやすいのは、複製先が「受け取った」ところまでを待ち、「適用し終えた」ところまでは待たないからです。ディスクへの書き出しまでを条件にすれば、主系が瞬時に消えても未達の更新はほぼ残りません。一方、同期を選ぶと複製先が1台でも詰まった瞬間に主系の書き込みが止まる。同期を採るなら、待ち先の候補を複数指定して1台の不調で全体が止まらない構成にしておく必要があります。

PostgreSQLのsynchronous_commitで選べる待ち方の5段階

PostgreSQLはこの待ち方をsynchronous_commit1つで切り替えます。値はoff、local、remote_write、on、remote_applyの5段階で、後ろへ行くほど安全側かつ遅くなる。既定のonは「同期スタンバイのWALがディスクへ書き出されるまで待つ」挙動で、一般に準同期と呼ばれる範囲に相当します。

複製先で即座に読み取れることまで保証したい場合だけremote_applyを選びます。適用完了を待つぶんコミットは遅くなるため、全トランザクションへ一律に掛けるのは割に合わない。この値はセッション単位で変えられるので、整合性が要る処理だけ強めるのが折衷案になります。待ち先の指定はsynchronous_standby_namesで行い、ANY 1 (s1, s2, s3)のようにクォーラム形式で書けば、3台のうち1台が応答した時点で先へ進みます。

MySQL 8.4の準同期プラグインと旧master系構文の削除への対応

MySQLは既定が非同期で、準同期はプラグインを追加して有効化する形を採ります。8.4ではrpl_semi_sync_source（ソース側）とrpl_semi_sync_replica（レプリカ側）が用意され、旧来のrpl_semi_sync_master系は非推奨扱いになりました。新旧のプラグインを同一インスタンスへ同時に入れることはできません。

版の状況も押さえておきます。endoflife.dateの2026年8月時点の集計では、8.0系はExtended Supportが2026年4月末で終了し、現役のLTSは8.4系（Premier Supportが2029年4月まで）と9.7系（同2034年4月まで）という並びです。8.0系のまま複製を組む環境は移行順位が高い。もう1点、準同期でもソースが応答を待つのはタイムアウトまでで、超えれば自動的に非同期へ落ちます。「準同期だから欠損しない」という前提は、この時点で崩れます。

物理レプリケーションと論理レプリケーションで分かれる適用範囲

WALとbinlogをそのまま送る物理型が抱える版とスキーマの制約

物理レプリケーション（PostgreSQLのストリーミングレプリケーション）は、WALをそのまま複製先へ送り、ブロック単位で同じ変更を再現します。転送されるのはインスタンス全体で、テーブル単位の取捨選択はできません。複製先は読み取り専用の待機系となり、書き込みを受け付けない。

制約は2つあります。1つは主系と複製先でメジャーバージョンを揃える必要があること。もう1つは、アーキテクチャやブロックサイズが異なる環境をまたげないことです。裏を返せば、丸ごと同じものを作る用途では最も速く、負荷も軽い。障害時の切り替え先を用意する目的なら、まず物理型を検討します。

表単位で切り出せる論理型が向く異バージョン間の移行と集約の場面

論理レプリケーションは、変更を行の操作として抽出して送ります。PostgreSQLでは発行側にPUBLICATION、購読側にSUBSCRIPTIONを作り、対象のテーブルだけを選べる。MySQLでもバイナリログの形式をROWにしておけば同様に行単位の複製になります。

この方式が効くのは3つの場面です。メジャーバージョンをまたぐ移行でダウンタイムを数分へ縮めたいとき、複数システムのデータを1か所へ集約したいとき、特定テーブルだけを別系統の分析基盤へ流したいとき。複製先が書き込み可能な点も物理型との違いで、購読先に独自の索引や列を足せます。代償は適用コストの高さと、DDLが自動では伝播しないことです。列を追加したら購読側へ同じ変更を先に入れる手順が要ります。

PostgreSQL 18で入った衝突ログと並列適用と放置スロットの停止

2025年9月25日にリリースされたPostgreSQL 18系では、論理レプリケーションの運用に効く変更がまとまって入りました。適用時の書き込み衝突がログとpg_stat_subscription_statsで見えるようになり、これまで購読側で静かに壊れていた状態を検知できます。購読側のストリーミングは既定でparallelとなり、大きなトランザクションの適用が並列化されました。

運用事故の予防ではidle_replication_slot_timeoutの追加が効きます。使われなくなった複製スロットが残るとWALが際限なく溜まり、主系のディスクを埋めて停止させる。タイムアウトで自動的に無効化できるようになった意味は小さくありません。全データベースをまとめて対象にするpg_createsubscriber --allも加わりました。18系のEOLは2030年11月の予定なので、新規構築なら18系を起点に組むのが素直な選択です。

リードレプリカへの読み取り振り分けで壊れる処理と遅延の測り方

登録直後の再読み込みで値が消えるread-after-write不整合の回避

非同期複製でレプリカへ参照を流すと、必ずこの問題に当たります。ユーザーが登録ボタンを押し、主系へ書き込んだ直後の画面遷移で複製先を読むと、まだ複製が届いておらず「保存したはずのデータが無い」と見える。数十ミリ秒の遅延でも、画面遷移の速さの方が上回れば再現します。遅れているあいだ何が読めるのかという保証モデルと、自己書き込みの読み取りをアプリ側へ実装する手順は結果整合性の定義と読み取り設計を解説した記事にまとめています。

手当の順序は決まっています。まず、書き込み直後の一定時間は同一セッションの読み取りを主系へ固定する。それでも足りない一部の処理にだけ、PostgreSQLならremote_applyを効かせます。全体を同期にして解決しようとすると、書き込み全体の応答が犠牲になる。壊れるのは一部の画面だけなので、対処もその範囲へ限定するのが筋です。

複製遅延を秒とバイトの両面で捉える監視指標と警戒水準の決め方

遅延は2つの単位で見ます。時間で見るならPostgreSQLはpg_stat_replicationのwrite_lag、flush_lag、replay_lagの3列、MySQLはSHOW REPLICA STATUSのSeconds_Behind_Source、AWSのマネージドならCloudWatchのReplicaLagが該当する指標です。もう一方の単位は未適用のログ量で、LSNやバイナリログ位置の差分をバイトで取ります。

秒だけを見ていると判断を誤ります。書き込みが一時的に止まっている時間帯は、未適用のログが溜まっていても秒表示は小さく出るからです。逆にバイト差分だけでは業務影響が読めない。警戒水準は業務側から決めるのが確実で、たとえば「受注画面の再読み込みで不整合が許されるのは1秒まで」という要件があるなら、警告は1秒、重大は3秒という具合に段階を切ります。閾値を製品の既定値から借りてくると、実際の業務要件とずれたまま運用が始まります。

フロー制御で書き込みを絞り遅延の発散を抑えるマネージドの仕組み

遅延が発散し始めると、フェイルオーバーの所要時間も伸びます。切り替え先が未適用ぶんを追いつくまで昇格できないからです。AWSのRDS Multi-AZ DBクラスターは、この発散をフロー制御で抑えます。

MySQLではrpl_semi_sync_master_target_apply_lagが既定で120秒に設定され、遅延がこの上限へ近づくとトランザクション末尾へ遅れを挿入して書き込みを絞る。PostgreSQLでは拡張として実装され、リーダーの遅延が2分を超えると同様の絞り込みが入ります。閾値はflow_control.target_standby_apply_lagで調整できる。スループットを意図的に下げて遅延を守る設計思想のため、短いトランザクションが高頻度で走るOLTPには効く一方、バッチ由来の遅延には効きにくい。

マネージドサービスが肩代わりする複製とDRの範囲と残る設計判断

RDSのMulti-AZインスタンスとMulti-AZクラスターの構成差

Amazon RDSの冗長構成は2種類あり、複製の性質が違います。Multi-AZ DBインスタンス構成はスタンバイが1台で、これは読み取りに使えません。切り替え先を確保するためだけの待機系です。

もう一方のMulti-AZ DBクラスター構成は、AWS公式ユーザーガイドが「semisynchronous（準同期）」と明記する方式で、ライター1台とリーダー2台を3つのAZへ配置します。コミットには少なくとも1台のリーダーからの応答が要り、全レプリカでの適用完了までは待ちません。リーダーは自動フェイルオーバー先を兼ねつつ読み取りも捌けるため、待機系を遊ばせずに済みます。同じ「Multi-AZ」でも読み取り容量が増えるかが違う点は、見積もり段階で取り違えやすい部分です。

ストレージ層で複製するAuroraとリーダーの追加で伸びる読み取り

Auroraはさらに階層が違います。データベースエンジンではなく共有ストレージ層が複製を担い、リーダーは同じストレージボリュームを参照する。このため、リーダーを増やしてもライター側の負荷はほとんど増えません。仕組みと料金モデルの違いはAmazon Auroraの構成とRDSとの違いで整理しています。

ただし、ストレージ層の複製でも遅延がゼロになるわけではない点は同じです。read-after-writeの問題は構成を問わず残るので、書き込み直後の参照をどう扱うかはアプリケーション側で決めておく。マネージドが肩代わりするのは複製の実装と切り替えの自動化であって、整合性の設計そのものは手元に残ります。

Aurora Global Databaseで組む複数リージョンのDR構成と制約

リージョン全体の障害まで想定するなら、Aurora Global Databaseが選択肢に入ります。AWS公式ユーザーガイドによれば、プライマリ1リージョンに対して読み取り専用のセカンダリを最大10リージョンまで持て、専用インフラを経由する複製の遅延は「typically under a second（通常1秒未満）」とされる。セカンダリ側は通常のクラスタの上限15台に対し、16台までリーダーを置けます。

制約も併せて押さえます。書き込みを受けるのはプライマリだけで、セカンダリからの更新は書き込み転送の機能を経由する形になる。計画的な切り替えはスイッチオーバー、障害時はフェイルオーバーと操作が分かれ、マネージドな切り替えには両クラスタでメジャー・マイナーの版が一致している必要があります。グローバル構成ではマイナー版の自動アップグレードが効かないため、版の追随は自前の運用手順として組み込みます。

自前で複製基盤を組んでよい条件と見送るべき場面の判断基準の整理

RPOとRTOの目標値から逆算して構成の複雑さを決める設計の順序

構成から入ると必ず過剰になります。順序は逆で、まず業務側から2つの数字を取りに行く。何秒ぶんの更新なら失っても業務が回るか（RPO）、何分止まったら実害が出るか（RTO）です。この2つが決まらないうちにHA構成の設計を始めるのは、予算の使い道を決めずに見積もりを取るのと同じことになります。

目安を挙げます。RPOが数分でよくRTOも数十分許されるなら、複製すら要らずバックアップからの復元で足ります。RPOが数秒・RTOが数分なら、非同期複製と手動昇格で十分。RPOをゼロに寄せ、RTOを1分以内へ縮める要求が出て初めて、準同期と自動フェイルオーバーの検討へ進みます。稼働率の数字と設計手法の対応関係は可用性の指標と高可用性設計の考え方に整理があるので、目標値の妥当性はそちらで確かめてください。

repmgrやPatroniで自前HAを組むだけの人手が要る条件の線引き

自前で組んでよいのは、次の条件が揃うときだけだと考えています。オンプレミスやIaaS上でデータベースの版と設定を自分たちが握る必要があること、マネージドでは満たせない要件（特定の拡張、独自のパラメータ、規制上の配置制約）が実在すること、障害時に手を動かせる担当者を交代要員込みで確保できていること。3つ目が欠けたまま自動フェイルオーバーを入れると、誤検知で切り替わった後の復旧を誰も再現できません。

逆に、単に「落ちない構成が欲しい」だけならマネージドを選びます。PostgreSQLの自前HAで定番のrepmgrとPatroniは、前者が外部の合意ストアを要しない軽さ、後者がetcd等を前提としたKubernetes親和性を持ち味とする。構成手順と、フェンシングを内蔵しないという設計上の限界はrepmgrによるレプリケーション管理と自動フェイルオーバーで詳しく扱っています。

複製だけでは守れない範囲を見誤る典型的な失敗パターンの見分け方

最後に、見送るべき場面を条件付きで書きます。まず、バックアップの復元試験を一度も通していない段階でHA構成へ投資するのは順序が逆です。複製は論理破損を伝播させるので、守れる障害の範囲が重ならない。次に、スプリットブレインを人手で解決する手順が書けていないなら、自動フェイルオーバーは入れない方が被害は小さい。二重に書き込まれたデータを事後に統合する自動手段は存在せず、片方を捨てる判断が要ります。

そして3つ目。読み取り負荷が原因でないのにリードレプリカを足すのは、遅延という新しい障害要因を増やすだけで終わります。スロークエリと索引の見直しが先です。こうした構成の判断や、複製とバックアップとDRの役割分担を含むクラウド基盤の設計は、AWS・Google Cloud・Azureのインフラ構築支援でも相談を受けています。

よくある質問

設計の相談で繰り返し出てくる論点を5つに絞って答えます。

レプリケーションとバックアップはどちらを先に用意すべきですか？

バックアップが先です。複製は誤った更新もそのまま複製先へ伝えるため、削除ミスやアプリケーションのバグ、ランサムウェアによる暗号化からはデータを守れません。バックアップの取得と、実際に復元できることの確認まで済ませたうえで、可用性の目標に応じて複製を追加する順序が安全になります。復元試験を通していない環境でHA構成へ先に投資すると、守れる障害の範囲が偏ります。

同期レプリケーションにすればデータは絶対に失われませんか？

失われない範囲は限定されます。同期構成でコミット済みの更新は複製先にも存在しますが、複製先が応答しないときに主系が非同期へ切り替わる実装（MySQLの準同期のタイムアウトなど）では、その時間帯の更新が欠ける可能性が残ります。また同期は論理破損に無力です。何が守れて何が守れないかを切り分け、方式の選択とバックアップ設計を別々に決めてください。

リードレプリカを増やせば書き込み性能も上がりますか？

上がりません。書き込みを受け付けるのは主系1台のままで、レプリカが増えるほど転送と適用の負荷はむしろ増えます。参照が負荷の大半を占める構成なら効果は大きいものの、書き込みが上限に張り付いている場合は別の手立てが要る。インスタンスの増強、不要データの退避、それでも足りなければ水平分割という順序で検討します。

レプリカ遅延はどのくらいまでなら許容してよいですか？

製品の既定値ではなく業務要件から決めます。登録直後の再読み込みで不整合が見えてはいけない画面があるなら、その処理は遅延の大小に関わらず主系へ振り分けるのが確実です。集計や一覧のように数秒遅れても実害がない処理だけをレプリカへ流し、警告と重大の2段階で閾値を設定します。フェイルオーバー時間は遅延の解消時間に引きずられる点も考慮に入れてください。

マネージドサービスに寄せれば複製の設計は不要になりますか？

不要にはなりません。マネージドが肩代わりするのは複製の実装と切り替えの自動化までで、どの処理をレプリカへ流すか、遅延をどこまで許すか、リージョン障害まで守るかという判断は手元に残ります。RDSのMulti-AZ DBインスタンスとMulti-AZ DBクラスターのように、同じ名前でも読み取り容量が変わる選択肢もあるため、要件との突き合わせは自分たちで行う必要があります。

関連記事

• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断：Multi-AZ構成を含むマネージドDBの全体像を確認できます
• データベースとは？種類・DBMSとRDB/NoSQLの選び方：複製の前提になるデータベースの基礎を整理しています
• フォールトトレラントとは？耐障害性と高可用性の違い：止めない設計と早く戻す設計の考え方を比較しています
• 冗長化とは？二重化との違い・種類と構成、企業の設計判断：データベース以外も含めた冗長化の全体像を扱っています