PostgreSQLは素晴らしいプロジェクトであり、驚くべき速度で進化しています。一連のブログ投稿を使用して、バージョン全体でPostgreSQLのフォールトトレランス機能の進化に焦点を当てます。これはシリーズの2回目の投稿であり、レプリケーションと、PostgreSQLのフォールトトレランスと信頼性におけるレプリケーションの重要性について説明します。
最初から進化の進展を目撃したい場合は、シリーズの最初のブログ投稿：PostgreSQLのフォールトトレランスの進化を確認してください。
PostgreSQLレプリケーション
データベースレプリケーション コピーを維持するために使用されるテクノロジーを説明するために使用する用語です リモート上の一連のデータの システム。実行中のシステムの信頼できるコピーを保持することは、冗長性の最大の懸念事項の1つであり、私たちは皆、データの保守可能で使いやすく安定したコピーが好きです。
基本的なアーキテクチャを見てみましょう。通常、個々のデータベースサーバーはノードと呼ばれます 。レプリケーションに関与するデータベースサーバーのグループ全体は、クラスターと呼ばれます。 。ユーザーが変更を加えることができるデータベースサーバーは、マスターと呼ばれます。 またはプライマリ 、または変更のソースとして説明される場合があります。 のみのデータベースサーバー 読み取り専用アクセスを許可することは、ホットスタンバイとして知られています。 。 （ホットスタンバイの用語は、スタンバイモードのタイトルで詳しく説明されています。 ）
レプリケーションの重要な側面は、データの変更がマスターでキャプチャされてから、他のノードに転送されることです。場合によっては、ノードがデータ変更を他のノードに送信することがあります。これは、カスケードと呼ばれるプロセスです。 またはリレー 。したがって、マスターは送信ノードですが、すべての送信ノードがマスターである必要はありません。多くの場合、レプリケーションは、複数のマスターノードが許可されているかどうかによって分類されます。この場合、レプリケーションはマルチマスターレプリケーションと呼ばれます。 。
PostgreSQLが時間の経過とともにレプリケーションをどのように処理しているか、およびレプリケーションの条件によるフォールトトレランスの最新技術を見てみましょう。
PostgreSQLレプリケーション履歴
歴史的に（2000年から2005年頃）、Postgresは単一ノードのフォールトトレランス/リカバリにのみ集中しており、これは主にWALのトランザクションログによって達成されます。フォールトトレランスは部分的にMVCC（マルチバージョン同時実行システム）によって処理されますが、これは主に最適化です。
ログ先行書き込みは、PostgreSQLの最大のフォールトトレランス方式であり、現在もそうです。基本的には、すべてを書き込み、それらを再生することで障害の観点から回復できるWALファイルを用意するだけです。これは単一ノードアーキテクチャには十分であり、レプリケーションは複数ノードでフォールトトレランスを実現するための最良のソリューションであると考えられています。
Postgresコミュニティは、レプリケーションはPostgresが提供すべきではなく、外部ツールで処理する必要があると長い間信じていました。そのため、SlonyやLondisteなどのツールが存在するようになりました。 （このシリーズの次のブログ投稿で、トリガーベースのレプリケーションソリューションについて説明します。）
最終的に、1つのサーバーの許容範囲では不十分であり、より多くの人々がハードウェアの適切なフォールトトレランスと適切な切り替え方法を要求することが明らかになりました。これはPostgresに組み込まれているものです。これは、物理（および物理ストリーミング）レプリケーションが実現したときです。
投稿の後半ですべてのレプリケーション方法について説明しますが、メジャーリリースごとのPostgreSQLレプリケーション履歴の時系列イベントを見てみましょう。
- PostgreSQL 7.x（〜2000）
- レプリケーションはコアPostgresの一部であってはなりません
- Londiste – Slony（トリガーベースの論理レプリケーション）
- PostgreSQL 8.0（2005）
- ポイントインタイムリカバリ（WAL）
- PostgreSQL 9.0（2010）
- ストリーミングレプリケーション（物理）
- PostgreSQL 9.4（2014）
- 論理デコード（チェンジセット抽出）
物理レプリケーション
PostgreSQLは、ほとんどのリレーショナルデータベースが行うことでコアレプリケーションのニーズを解決しました。 WALを取得し、ネットワーク経由で送信できるようにしました。次に、これらのWALファイルは、読み取り専用で実行されている別のPostgresインスタンスに適用されます。
読み取り専用スタンバイインスタンスは、変更（WALによる）と書き込み操作のみを適用します。 同じWALログから再度取得します。これは基本的に、レプリケーションのストリーミングの方法です。 メカニズムが機能します。当初、レプリケーションは元々すべてのファイルを出荷していました–ログの出荷- 、しかし後でストリーミングに進化しました。
ログ配布では、 archive_commandを介してファイル全体を送信していました 。そこでのロジックは非常に単純です。送信するだけです。 アーカイブとログ 16MBのWALファイル全体のように、どこかにそれを配置してから、適用します。 どこかに移動してから、フェッチします。 次のものと適用 あれとそれはそのようになります。その後、PostgreSQLバージョン9.0でlibpqプロトコルを使用してネットワーク経由でストリーミングするようになりました。
既存のレプリケーションは、より適切には物理ストリーミングレプリケーションとして知られています。 あるノードから別のノードに一連の物理的な変更をストリーミングしているためです。つまり、挿入するとき 生成するテーブルへの行変更レコード 挿入の場合 さらに、すべてのインデックスエントリ 。
VACUUMの場合 変更レコードも生成するテーブル。
また、物理ストリーミングレプリケーションは、すべての変更をバイト/ブロックレベルで記録します。 、すべてを再生する以外のことを行うのは非常に困難です
図1物理レプリケーション
図1は、物理レプリケーションが2つのノードでどのように機能するかを示しています。クライアントはマスターノードでクエリを実行し、変更はトランザクションログ（WAL）に書き込まれ、ネットワーク経由でスタンバイノードのWALにコピーされます。次に、スタンバイノードのリカバリプロセスがWALから変更を読み取り、クラッシュリカバリの場合と同じようにデータファイルに適用します。スタンバイがホットスタンバイの場合 モードの場合、クライアントはこれが発生している間、ノードで読み取り専用クエリを発行できます。
注： 物理レプリケーションとは、ネットワークを介してマスターノードからスタンバイノードにWALファイルを送信することを指します。ファイルは、scp、rsync、ftpなどのさまざまなプロトコルで送信できます…違い 物理レプリケーションの間 および物理ストリーミングレプリケーション ストリーミングレプリケーションは、WALファイルを送信するために内部プロトコルを使用します（送信者 およびレシーバープロセス ）
スタンバイモード
複数のノードが高可用性を提供します。そのため、最近のアーキテクチャには通常スタンバイノードがあります。スタンバイノードにはさまざまなモードがあります（ウォームスタンバイとホットスタンバイ）。以下のリストは、さまざまなスタンバイモードの基本的な違いを説明し、マルチマスターアーキテクチャの場合も示しています。
ウォームスタンバイ
すぐにアクティブ化できますが、アクティブ化されるまで有用な作業を実行できません。同じベースバックアップファイルがロードされている別のマシンに一連のWALファイルを継続的にフィードすると、ウォームスタンバイシステムができます。いつでも2台目のマシンを起動でき、ほぼ最新のコピーが作成されます。データベース。ウォームスタンバイでは読み取り専用クエリは許可されていません。図2は単にこの事実を表しています。
図2ウォームスタンバイ
ウォームスタンバイの回復パフォーマンスは十分に良好であるため、スタンバイがアクティブ化されると、通常、完全な可用性からほんの少し離れます。その結果、これはウォームスタンバイ構成と呼ばれ、高可用性を提供します。
ホットスタンバイ
ホットスタンバイは、サーバーがアーカイブリカバリモードまたはスタンバイモードのときにサーバーに接続して読み取り専用クエリを実行する機能を表すために使用される用語です。これは、レプリケーションの目的と、バックアップを非常に正確に目的の状態に復元する場合の両方に役立ちます。
図3ホットスタンバイ
ホットスタンバイという用語は、ユーザーがクエリの実行を継続したり、接続を開いたままにしたりしながら、サーバーがリカバリから通常の操作に移行する機能も指します。図3は、スタンバイモードで読み取り専用クエリが可能であることを示しています。
マルチマスター
すべてのノードが読み取り/書き込み作業を実行できます。 （シリーズの次のブログ投稿でマルチマスターアーキテクチャについて説明します。）
WALレベルパラメータ
wal_levelの設定には関係があります postgresql.confファイルのパラメータとこの設定は何に適していますか。 PostgreSQLバージョン9.6の関係を示すためのテーブルを作成しました。
フェイルオーバーとスイッチオーバー
シングルマスターレプリケーションでは、マスターが停止した場合、スタンバイの1つが代わりになる必要があります（プロモーション ）。そうしないと、新しい書き込みトランザクションを受け入れることができません。したがって、マスターとスタンバイという用語の指定は、ある時点で任意のノードが引き受けることができる役割にすぎません。マスターの役割を別のノードに移動するには、スイッチオーバーという名前の手順を実行します 。
マスターが死亡して回復しない場合、より深刻な役割の変更はフェイルオーバーとして知られています。 。多くの点で、これらは類似している可能性がありますが、イベントごとに異なる用語を使用すると役立ちます。 （フェイルオーバーとスイッチオーバーの条件を知っていると、次のブログ投稿でタイムラインの問題を理解するのに役立ちます。）
結論
このブログ投稿では、PostgreSQLレプリケーションと、フォールトトレランスと信頼性を提供するためのPostgreSQLレプリケーションの重要性について説明しました。物理ストリーミングレプリケーションについて説明し、PostgreSQLのスタンバイモードについて説明しました。フェイルオーバーとスイッチオーバーについて説明しました。次のブログ投稿でPostgreSQLのタイムラインを続行します。
参照
PostgreSQLドキュメント
PostgreSQL5432での論理レプリケーション…PetrJelinekによるMeetUsプレゼンテーション
PostgreSQL 9管理クックブック–第2版