PostgreSQLのSlonyレプリケーションに関するエキスパートガイド

Slonyとは何ですか？

Slony-I（以降、単に「Slony」と呼びます）は、バージョン8.0より前にさかのぼるPostgreSQL用のサードパーティのレプリケーションシステムであり、レプリケーションの古いオプションの1つとして利用できます。これは、「マスターから複数のスレーブへ」のソリューションであるトリガーベースのレプリケーション方法として機能します。

Slonyは、複製される各テーブル（マスターとスレーブの両方）にトリガーをインストールすることで動作し、テーブルがINSERT、UPDATE、またはDELETEを取得するたびに、変更されたレコードとその変更内容をログに記録します。「slonデーモン」と呼ばれる外部プロセスは、他のクライアントと同じようにデータベースに接続し、マスターから変更をフェッチしてから、マスターにサブスクライブされているすべてのスレーブノードでそれらを再生します。パフォーマンスの高いレプリケーションセットアップでは、この非同期 レプリケーションは、マスターより1〜20秒遅れると予想されます。

この記事の執筆時点で、Slonyの最新バージョンはバージョン2.2.6であり、PostgreSQL8.3以降をサポートしています。サポートは今日までマイナーアップデートで継続されますが、PostgreSQLの将来のバージョンでトランザクション、関数、トリガー、またはその他のコア機能の基本的な機能が変更された場合、Slonyプロジェクトはそのような抜本的な新しいアプローチをサポートするために大規模なアップデートを中止することを決定する可能性があります。

PostgreSQLのマスコットは、ロシア語で「小さな象」を意味する「Slonik」として知られる象です。この複製プロジェクトは、相互に複製する多くのPostgreSQLデータベースに関するものであるため、象（複数形）を表すロシア語のSlonyが使用されます。

コンセプト

クラスター：Slonyレプリケーションのインスタンス。
ノード：Slonyレプリケーションノードとしての特定のPostgreSQLデータベース。レプリケーションセットのマスターまたはスレーブとして動作します。
レプリケーションセット：レプリケートされるテーブルやシーケンスのグループ。
サブスクライバー：サブスクライバーは、レプリケーションセットにサブスクライブされているノードであり、マスターノードからそのセット内のすべてのテーブルとシーケンスのレプリケーションイベントを受信します。
Slonyデーモン：レプリケーションを実行するメインワーカーであるSlonyデーモンは、レプリケーションセット内のすべてのノードに対してキックオフされ、マスターノードだけでなく管理するノードへのさまざまな接続を確立します。

使用方法

Slonyは、ソースによって、またはRed HatおよびDebianベースのLinuxディストリビューションで利用可能なPGDG（PostgreSQL Global Development Group）リポジトリを介してインストールされます。これらのバイナリは、レプリケーションシステムにマスターノードまたはスレーブノードのいずれかを含むすべてのホストにインストールする必要があります。

インストール後、「slonik」バイナリを使用していくつかのコマンドを発行することにより、Slonyレプリケーションクラスターがセットアップされます。「slonik」は、slonyクラスターを初期化および維持するための、独自のシンプルでありながら独自の構文を備えたコマンドです。これは、レプリケーションを担当する実行中のSlonyクラスターにコマンドを発行するためのメインインターフェイスです。

Slonyとのインターフェースは、カスタムslonikコマンドを作成するか、-with-perltoolsフラグを使用してslonyをコンパイルすることで実行できます。このフラグは、必要なこれらのslonikスクリプトの生成に役立つ「altperl」スクリプトを提供します。

Slonyレプリケーションクラスターの作成

「レプリケーションクラスター」は、レプリケーションの一部であるデータベースのコレクションです。レプリケーションクラスターを作成するときは、以下を定義するinitスクリプトを作成する必要があります。

必要なSlonyクラスターの名前
レプリケーションの各ノード部分の接続情報。それぞれに不変のノード番号が付いています。
「レプリケーションセット」の一部としてレプリケートされるすべてのテーブルとシーケンスを一覧表示します。

スクリプトの例は、Slonyの公式ドキュメントにあります。

実行されると、slonikは定義されたすべてのノードに接続し、それぞれにSlonyスキーマを作成します。 Slonyデーモンがキックオフされると、スレーブ上のレプリケートされたテーブル内のすべてのデータがクリアされ（存在する場合）、すべてのデータがマスターからスレーブにコピーされます。その時点から、デーモンはマスターに記録された変更をすべてのサブスクライブされたスレーブに継続的に複製します。

巧妙な構成

Slonyは当初、マスターからマルチスレーブへのレプリケーションシステムであり、主にそのように使用されてきましたが、Slonyを単純なレプリケーションソリューションよりも便利にする他のいくつかの機能と巧妙な使用法があります。 Slonyは高度にカスタマイズ可能な性質を備えているため、管理者が既成概念にとらわれずに考えることができるさまざまな状況に対応できます。

カスケードレプリケーション

Slonyノードは、異なるノードのチェーンに沿ってレプリケーションをカスケードするように設定できます。マスターノードが非常に重い負荷をかけることがわかっている場合、スレーブを追加するたびにその負荷がわずかに増加します。カスケードレプリケーションを使用すると、マスターに接続された単一のスレーブノードを「転送ノード」として構成できます。転送ノードは、マスターノードの負荷を最小限に抑えながら、より多くのスレーブにレプリケーションイベントを送信する役割を果たします。

Slonyを使用したカスケードレプリケーション

スレーブノードでのデータ処理

PostgreSQLの組み込みレプリケーションとは異なり、スレーブノードは実際には「読み取り専用」ではなく、レプリケートされているテーブルのみが「読み取り専用」としてロックダウンされます。つまり、スレーブノードでは、処理されたデータを格納するためのレプリケーションの一部ではない新しいテーブルを作成することで、データ処理を実行できます。レプリケーションのテーブル部分には、スレーブおよびマスターとは異なる可能性のあるアクセスパターンに応じてカスタムインデックスを作成することもできます。

スレーブ上の読み取り専用テーブルでは、データの変更時にカスタムトリガーベースの関数を実行できるため、データをさらにカスタマイズできます。

スロニースレーブノードでのデータ処理

最小限のダウンタイムアップグレード

PostgreSQLのメジャーバージョンのアップグレードには非常に時間がかかる場合があります。データサイズとテーブル数によっては、アップグレード後の「分析」プロセスを含むアップグレードに数日かかる場合があります。 Slonyは異なるバージョンのPostgreSQLクラスター間でデータを複製できるため、マスターとしての古いバージョンとスレーブとしての新しいバージョンの間で複製を設定するために使用できます。アップグレードを行う場合は、「スイッチオーバー」を実行してスレーブを新しいマスターにすると、古いマスターがスレーブになります。アップグレードが成功とマークされたら、Slonyレプリケーションクラスターを廃止し、古いデータベースをシャットダウンします。

Slonyを使用してダウンタイムを最小限に抑えてPostgreSQLをアップグレードする

頻繁なサーバーメンテナンスによる高可用性

アップグレードの最小限のダウンタイムと同様に、サーバーのメンテナンスは、2つ以上のノード間で「スイッチオーバー」を実行し、更新やその他のメンテナンスでスレーブを再起動できるようにすることで、ダウンタイムなしで簡単に実行できます。スレーブがオンラインに戻ると、スレーブはレプリケーションクラスターに再接続し、レプリケートされたすべてのデータに追いつきます。データベースに接続しているエンドユーザーは長いトランザクションを中断している可能性がありますが、ホストの再起動/更新にかかる時間ではなく、スイッチオーバーが発生したときにダウンタイム自体が数秒になります。

ログ配布

一般的なソリューションではない可能性がありますが、Slonyスレーブは「ログ配布」ノードとして設定できます。このノードでは、レプリケーションを通じて受信するすべてのデータをSQLファイルに書き込んで、送信できます。これは、外部ドライブへの書き込みやスレーブデータベースへの手動転送など、さまざまな理由で使用できます。ネットワーク経由ではなく、圧縮して将来のバックアップ用にアーカイブしておくか、外部プログラムにSQLファイルを解析させて内容を変更します。

複数のデータベースデータ共有

任意の数のテーブルを自由に複製できるため、データベース間で特定のテーブルを共有するようにSlony複製セットを設定できます。同様のアクセスは、Foreign Data Wrappers（最近のPostgreSQLリリースで改善されています）を介して実現できますが、使用法によっては、Slonyを使用する方が良いソリューションになる場合があります。あるホストから別のホストに大量のデータをフェッチする必要がある場合、Slonyにそのデータを複製させることは、必要なデータが要求元のノードにすでに存在することを意味し、長い転送時間を排除します。

今日のホワイトペーパーをダウンロードするClusterControlを使用したPostgreSQLの管理と自動化PostgreSQLの導入、監視、管理、スケーリングを行うために知っておくべきことについて学ぶホワイトペーパーをダウンロードする

遅延レプリケーション

通常、レプリケーションは可能な限り高速であることが望まれますが、遅延が望まれるシナリオもあります。スレーブノードのslonデーモンは、lag_intervalを使用して構成できます。つまり、指定されたとおりにデータが古くなるまで、レプリケーションデータを受信しません。これは、何か問題が発生した場合に失われたデータにすばやくアクセスするのに役立ちます。たとえば、行が削除された場合、その行は1時間スレーブに存在し、すばやく取得できます。

知っておくべきこと：

レプリケーションの一部であるテーブルへのDDL変更は、slonikexecuteコマンドを使用して実行する必要があります。
複製するテーブルには、主キー、またはnull許容列のないUNIQUEインデックスが必要です。
マスターノードから複製されるデータは、データが機能的に生成された後に複製されます。つまり、データが「random（）」などを使用して生成された場合、結果の数値は、スレーブで「random（）」が再度実行されて別の結果を返すのではなく、スレーブに保存および複製されます。
Slonyレプリケーションを追加すると、サーバーの負荷がわずかに増加します。各テーブルには効率的に記述されていますが、各INSERT、UPDATE、およびDELETEをSlonyテーブルに記録するトリガーがあり、データベースのサイズとワークロードに応じて、サーバーの負荷が約2〜10％増加すると予想されます。

ヒントとコツ：

Slonyデーモンは、他のすべてのホストにアクセスできる任意のホストで実行できますが、最もパフォーマンスの高い構成は、管理しているノードでデーモンを実行することです。たとえば、マスターノードで実行されているマスターデーモン、スレーブノードで実行されているスレーブデーモン。
非常に大量のデータを使用してレプリケーションクラスターをセットアップする場合、最初のコピーに非常に長い時間がかかる可能性があります。つまり、キックオフからコピーが完了するまでに発生するすべての変更は、追いついて同期するのにさらに時間がかかる可能性があります。。これは、レプリケーションに一度にいくつかのテーブルを追加するか（非常に時間がかかる）、マスターデータベースのデータディレクトリコピーをスレーブに作成してから、OMITCOPYオプションを設定して「サブスクライブセット」を実行することで解決できます。本当。このオプションを使用すると、Slonyはスレーブテーブルがマスターと100％同一であると想定し、それをクリアしてデータをコピーしません。
このための最良のシナリオは、PostgreSQLの組み込みツールを使用してホットスタンバイを作成し、データを変更する接続がゼロのメンテナンスウィンドウ中に、スタンバイをマスターとしてオンラインにし、2つの間のデータの一致を検証し、 OMIT COPY =trueのslonyレプリケーションクラスター、そして最後にクライアント接続を再度有効にします。ホットスタンバイのセットアップには時間がかかる場合がありますが、このプロセスによってクライアントに大きな悪影響が生じることはありません。

コミュニティとドキュメント

Slonyのコミュニティは、http：//lists.slony.info/mailman/listinfo/slony1-generalにあるメーリングリストにあります。これにはアーカイブも含まれています。

ドキュメントは公式ウェブサイトhttp://slony.info/documentation/で入手でき、ログ分析、およびslonyとのインターフェースの構文仕様に関するヘルプを提供します。