私は自分自身を少し探検家だと思っています。あることではそうです。私は通常、いつもおなじみのレストランに同じ食べ物を注文します。失望を恐れて、何か新しいことに挑戦することへの不安を上回ります。
そしてもちろん、空腹の人間はちょうどよく食べる傾向がありますか？
それでも、テクノロジー、特にSQL（PostgreSQL）に関して言えば、私は、学ぶことを望んで、しばしば、なじみのない領域に全速力でつまずく傾向があります。経験よりも学ぶためのより良い方法は何ですか？
では、このとりとめのないことは、PostgreSQLの論理レプリケーションとストリーミングレプリケーションと一体何の関係があるのでしょうか？
私はこれらの分野の完全な初心者であり、知識はありません。はい、私はPostgresのこの分野で、天体物理学と同じくらい多くのことを理解しています。
知識がゼロだと言いましたか？
したがって、このブログ投稿では、これらのタイプのレプリケーションの違いを消化しようとします。実社会での実務経験がなければ、私はあなたに「すべてを終わらせる」を約束することはできません。 '複製用の原稿。
おそらく、この特定の分野にあまり精通していない他の人（私など）は、このブログ投稿の恩恵を受けるでしょう。
経験豊富なユーザーと開発者が一緒に乗ってくれました。下のコメントでお会いしましょう。
いくつかの基本定義
広義の意味で、レプリケーションとはどういう意味ですか？
ウィクショナリーで定義されているレプリケーションには、次のように書かれています。
「オブジェクト、人物、場所、またはアイデアを模倣または複製するためのプロセス。」
それでも、そこにある5番目にリストされている項目は、このブログ投稿により当てはまります。私たちもそれを確認する必要があると思います：
「（コンピューティング）すべてのユーザーが同じレベルの情報を共有できるように、あるコンピューターまたはサーバーの1つのデータベースを別のデータベースに頻繁に電子データでコピーするプロセス。システムの耐障害性を向上させるために使用されます。」
今、私たちが入ることができる何かがあります。あるサーバーまたはデータベースから別のサーバーにデータをコピーすることについて言及していますか？私たちは今、おなじみの領域にいます...
では、その定義からわかっていることを追加すると、ストリーミングレプリケーションと論理レプリケーションの定義は何ですか？
PostgreSQLWikiが提供するものを見てみましょう：
ストリーミングレプリケーション：「WALXLOGレコードを継続的に出荷し、いくつかのスタンバイサーバーに適用して、それらを最新の状態に保つ機能を提供します。
また、PostgreSQLドキュメントには、論理レプリケーションの次の定義があります。
「論理レプリケーションは、レプリケーションID（通常は主キー）に基づいてデータオブジェクトとその変更をレプリケートする方法です。正確なブロックアドレスとバイトごとのレプリケーションを使用する物理レプリケーションとは対照的に、論理という用語を使用します。 "
第19.6章公式ドキュメントからの複製には、すばらしいものがぎっしり詰まっているので、必ずそのソースにアクセスしてください。
以下では、素人の用語の違いを伝えようと思います。 （私がつまずいた場合、私は初心者であることを忘れないでください。）これは極端な「高レベル」の概要です。
論理レプリケーション
「ソース」データベースは、CREATEPUBLICATIONコマンドを使用してPUBLICATIONを作成します。 （私はこれを簡単に「送信者」と考えています。）
ドキュメントでは、それを発行者と呼んでいます。
このパブリッシャーデータベースには、複製するデータが含まれています。それでも、複製するものが必要であり、これがパブリッシャーのカウンターパートの出番です。「サブスクライバー」。オンライン検索で見つけたものから、複数のサブスクライバーを持つことが実際的な設定であるため、別の複数形を投げたことに注意してください。
「サブスクライバー」（レプリカデータベースと考えることもできます）は、接続情報を定義する「ソース」データベース（パブリッシャー）へのサブスクリプションと、それがサブスクライブするすべてのパブリケーションを作成します。
サブスクライバーがパブリッシャーになることも可能で、他のサブスクライバーがサブスクライブできる独自のPUBLICATIONを作成します。
今何が起こりますか？
パブリッシャーで発生するデータ変更はすべて、サブスクライバーに送信されます。箱から出してすぐに使えるものがすべてですが、特定の操作（つまり、INSERT、UPDATE、またはDELETE）に構成または制限することができます。
ハイレベルの例：
パブリッシャーの特定のテーブルの1つまたは複数の行を更新すると、それらの更新と変更は、サブスクライバーのインスタンスまたはそのタイプの構成が実装されている場合は複数のサブスクライバーに複製されます。
言及する価値があると感じた覚えておくべきことがいくつかあります：
- パブリッシャーデータベースのwal_level構成を論理に設定する必要があります。
- 論理レプリケーションには、DDL（データ定義言語）コマンドはありません。
- ドキュメントの[競合]ページから：「論理レプリケーションは、サブスクライバノードでローカルに変更された場合でもデータが更新されるという点で、通常のDML操作と同様に動作します。受信データが制約に違反すると、レプリケーションが停止します。これはは競合と呼ばれます。UPDATEまたはDELETE操作を複製する場合、データが欠落していても競合は発生せず、そのような操作は単にスキップされます。」
- パブリッシャーテーブルには、影響を受ける行のレプリカでDML（UPDATEおよびDELETE）操作を適切に複製するために、自身を識別する方法（「レプリカID」と呼ばれる）が必要です。テーブルに主キーがある場合、これがデフォルトです（私には適切な選択のようです）が、主キーがない場合は、他の構成オプションを使用できます。他の候補キーが存在しない場合（「フル」と呼ばれる）、行全体を使用できますが、ドキュメントには、これは通常、効率的なソリューションではないと記載されています。 （設定方法の下位レベルの説明については、ドキュメントのREPLICA IDENTITYセクションを参照してください）
制限
セクション31.4のドキュメント。制限には、私が説明する制限に関するいくつかの重要な注意事項があります。正確な言い回しについては、上記のリンク先のページを確認してください。
- データベーススキーマおよびDDLコマンドは、レプリケーションではサポートされていません。最初はpg_dumpを使用することをお勧めしますが、それでも、スキーマの変更や進歩をすべてのレプリカに更新する必要があります。
- シーケンス列のデータが複製されます。ただし、シーケンス自体は開始値のみを反映します。読み取りの場合、それは問題ありません。ただし、これがフェイルオーバーの頼みの綱である場合は、自分で現在の値に更新する必要があります。ドキュメントはここでpg_dumpを提案しています。
- 切り捨てはまだサポートされていません。
- 大規模なオブジェクトのレプリケーションはサポートされていません。
- ビュー、マテリアライズドビュー、パーティションルートテーブル、または外部テーブルは、パブリッシャーとサブスクライバーのどちらでもサポートされていません。
報告された一般的なユースケース
- データベース全体を複製するのではなく、実際に複製する特定のデータとデータの変更にのみ関心があります。
- 分析シナリオなど、読み取り専用操作用のレプリカが必要な場合。
- ユーザーまたはユーザーのさまざまなサブセットに、データへのアクセスを制限または監視することを許可します。
- データの配布。
- 他のPostgreSQLバージョンとの互換性。
ストリーミングレプリケーション
ストリーミングレプリケーションの調査、読み取り、および調査から、私が最初に収集したことの1つは、非同期（デフォルト）または同期レプリケーションのいずれかを設定することを選択することです。
ああ、もっとなじみのない用語ですね
これが両方の私の「高レベル」の定義です：
非同期レプリケーションでは、トランザクションがプライマリでコミットされた後、同じトランザクションがコミットされてレプリカに書き込まれるときにわずかな遅延が発生します。このタイプの構成では、データが失われる可能性があります。
- 1つは、マスターがクラッシュしたとします。
- 2つ目は、レプリカがマスターよりはるかに遅れているため、レプリカが「最新」であるために必要なデータと情報を破棄していることです。
ただし、同期レプリケーションでは、マスターサーバーとレプリカサーバーの両方で確認されるまで、トランザクションは完了したとは見なされません。これにより、両方のサーバーのWALへのコミットが書き込まれます。
私が理解しているように、これはマスターへの書き込みも確認され、レプリカにも書き込まれていることを意味します。
これがセクション26.2.8からの公式の説明です。公式ドキュメントの同期レプリケーション：
「同期レプリケーションを要求する場合、書き込みトランザクションの各コミットは、コミットがプライマリサーバーとスタンバイサーバーの両方のディスクの先行書き込みログに書き込まれたという確認が受信されるまで待機します。 「
ドキュメントの別の箇所には、（私の意見では）必要なものの概要があり、大きな利点があります。「データが失われる可能性があるのは、プライマリとスタンバイの両方が同時にクラッシュした場合だけです。」
不可能なことは何もありませんが、それでもデータのコピーが残らないことを保証します。
さて、これらのセットアップ構成の1つを選択する必要があることはわかっていますが、全体的な要点は何ですか？
簡単に言うと、ストリーミングレプリケーションは、1つのデータベースサーバー（マスターまたはプライマリ）から「レプリカ」（受信データベース）にWAL（ログ先行書き込み）ファイルを送信して適用します。
ただし、ここで覚えておくべき注意点があります。潜在的に、マスターからのWALファイルは、スタンディがそれらを取得する前にリサイクルできます。これを軽減する1つの方法は、wal_keep_segments設定をより高い値に増やすことです。
ストリーミングレプリケーションのポイント
関連リソースPostgreSQL用ClusterControlPostgreSQLストリーミングレプリケーション-詳細な詳細PostgreSQL用Slonyレプリケーションのエキスパートガイド- デフォルトでは、ストリーミングレプリケーションは非同期です。つまり、マスターでコミットされたトランザクションとレプリカでの可視性の間に遅延（おそらく小さい）があります。
- レプリカはネットワーク接続を介してマスターに接続します。
- 認証に注意してください。ドキュメントからここを参照してください：「レプリケーションのアクセス権限を設定して、信頼できるユーザーのみがWALストリームを読み取ることができるようにすることが非常に重要です。これは、WALストリームから特権情報を簡単に抽出できるためです」
ストリーミングレプリケーションを使用する場合
- 一般的な使用法（特に分析）では、プライマリサーバーの負荷を軽減するための「読み取り専用」レプリカが提供されます。
- 高可用性環境が必要です。
- プライマリがダウンした場合にホットスタンバイサーバーにフェイルオーバーするための便利なセットアップ。