経営者にとってシステムを運用するに当たり"最善の諸慣行"をまとめた入手可能でドキュメントに基づいて行いたいという希望は共通しています。この種のドキュメントは ISO 9000、ISO 9001、およびその他の組織認定書では基本的なものです。
Slony-I を使用するそれぞれの組織は独特で、特有の運用特質を反映した特有の経営方針に対する必要性を持っている点に触れ、"最善の諸慣行"についての論議を開始する事はやりがいがあります。Slony-I は フェイルオーバのような、物事に対して独自の方針を無理強いしないのはこのような理由からです。それらはそれぞれのネットワークの全体的な形状や、データベースサーバのまとまりや、それぞれのサーバの使用形式に基づいて決定される必要があります。
とは言っても、早い時期に Slony-I を導入した者が発見し数多くの事は、少なくとも検討に値する方針の提案について手助けになるでしょう。
Slony-I は問題を引き起こす数え切れない程の場合を抱えている、入り組んだ複数クライアント、複数サーバシステムになっています。
自然の帰結として、如何なる環境的な"散乱状態"が予測できない問題を引き起こしたり、本来の問題を覆い隠したりするので、均整のとれた環境を維持することは確かに価値があります。
数多くのユーザは Slony-I バージョン、ローカルのライブラリ、そして PostgreSQL のライブラリ間での誤った組合せによる諸問題を報告して来ています。詳細には影響力があります。どのソフトウェアのどのバージョンがどのホスト上で実行されているか良く判っている必要があります。
基本:明白で、安定した UTC もしくは GMT の様な時間帯を使用する事。
ユーザは CUT0 もしくは WST と言った PostgreSQL が認識できなかった時間帯をシステムで使用した場合問題に葬具しました。 PostgreSQL が正しく認識できる時間帯を使用する事が必要です。
更に、使用に際して選ぶべき時間帯はサマータイムによる時刻の移行が無いものです。
"地理的に偏りの無い"選択としては TZ=UTC もしくは TZ=GMT の様です。
項3.3も参照してください。
基本:長期に渡るトランザクションは悪である。
FAQ に pg_listener の 成長に関する項目があり、この問題を多少詳細に記述しています。長いとか短いと言うのは、長期に渡るトランザクションは数多くの有害な作用を含んでいる事です。それらは特に、ロックを保持し続けたり、vacuum が効果をあげるのを妨げる等、の"オリジン"ノードで問題です。
フェイルオーバに対する施策は早期に計画されていなければなりません。
この事は単純に、オートメーション化するのに対立するものとして、何が何に対して失敗するのかの優先順位について考慮を払うことです。しかしながら、事前に何をするかを知っておく事は失敗をする数を少なくします。
アフィリアスにおいて、内部手引書 [The 3AM Unhappy DBA's Guide to...] は"好まざる"事態になった場合に何をするかという照合表を提供しました。この種の資料はアプリケーションの実行に大いに特定されているので、それぞれ独自のドキュメントを作成する必要があります。
VACUUM 施策は注意を払って定義される必要があります。
上記の如く、"長期に渡るトランザクションは悪です"。VACUUM もこの限りではありません。巨大なテーブル上の VACUUM は、全ての既知の有害な作用を持った長期実行のトランザクションを開きます。
それぞれのネットワークに対し中央サーバ上で全ての slon を走らせる事は好ましい事であると実証されています。
データベースと多くの通信を行うことから、それぞれの slon はそのノードがサービスを提供している限り同じローカルネットワーク上のホストで実行されなければなりません。
論理的には、"最善の"速度はサービスを提供しているデータベースサーバ上で slon を実行することで得られます。
実際は、1 ダースほどのサーバに散らばった slon プロセスを持つと、それらの構成を変更するのに全ての束になったサーバにログオンしなければならないのでまさに管理が不自由です。アプリケーションユーザに成るために sudo を使わなければならないユーザの環境ではひどく不便です。slon プロセスをローカルネットワーク毎に 1 つのサーバ上にまとめると、かなり管理が楽になります。1 つのスクリプトで、開始、監視、終了、および別な方法で近隣にあるノードの全てを保守できるようになります。
これは同時に、構成エラーの重複を防ぎ、構成データと構成スクリプトは一ヶ所で保守できることを暗示しています。
データベーススキーマ変更の節に、データベーススキーマ変更の取扱いの際に有用とされるいくつかの施策が概説されています。
主キーの取扱い
レプリケーションセットの節で論議されていますが、もしそれぞれのレプリケートされるテーブルに実(true)主キー制約があれば理想的です。"候補(candidate)主キー"の使用も受け入れられています。
Slony-I 定義のキーを候補主キーを導入するために使用する事は推奨されません。と言うのは、導入された一意性インデックスが原因でこのテーブルの更新が失敗する可能性があり、Slony-I アプリケーションに対し新規の故障モードを通知するからです。
グループ化テーブルをセットにすることはどのようにしてテーブルとシーケンスをグループ化しレプリケーションセットとするかを決定する戦略を暗示しています。
大規模なデータを削除可能な行為には大きな注意が必要なことは明らかです。Slony-I レプリケーションから諸々の削除の節で、Slony-I が提要する異なった種類の"削除"について論じます。
ある種の Slony-I の操作、特に set add table , move set , lock set , and execute script は複製されるテーブル上で排他ロックの取得を必要とします。
データベース上の行為の種類によっては、データベースの中断(瞬間であることを期待)に要する効果があったり、無かったりします。
Slony-I 特有のユーザ名
Slony-I が使用する slony ユーザを、汎用の postgres もしくは pgsql ユーザと明白に区別して定義することは有用であると認められています。
vacuum を掛けたりバックアップを行うような全ての種類の自動的"保守"行為が、単独の PostgreSQL ユーザの"所有権限"で実行されると、非常に簡単にデッドロック問題に遭遇します。
例えば、大規模の SUBSCRIBE_SET 事象が進行中であるデータベースに対し、一連の vacuums を不意に実行すると、データ複写作業のため数時間を要するロールバックのデッドロックになることがあります。
そうはしないで、もしも異なった保守の約割りが異なるユーザによって行われれば、SUBSCRIBE_SET のような生死にかかわる操作中、pg_hba.conf レベルで他のユーザを締め出し、slony ユーザのみの入室を許可し、結果としてサブスクリプションが進行中であっても問題を引き起こすリスクを大幅に軽減できます。
経路構成
経路通信の節で Slony-I が機能するために、どのようなネットワーク接続がふさわしくあるべきかにまつわる問題を論議します。
監視経路の節でテーブル sl_listen にまつわる問題を論議します。
Slony-I 1.1 時点では、そのコンテンツは Slony-I が利用できる通信情報に基づいて自動的に計算されます。これは手作業により構成される必要があった早期のバージョンで発見された問題を緩和するものです。技術的にはできるはずの、ノード間でのお互いの通信が失敗すると言う、多くの見かけ上不可解な通信障害は不正確な監視経路構成の帰結です。
slon の構成
バージョン 1.1 現在、slon 構成はコマンドラインもしくは構成ファイルのいずれかから導かれます。"最善の"方策は 2 つのオプションにより明らかになります。
コマンドラインオプションによる構成
この手法は現在使用中の全てのオプションがプロセス環境で見る事ができる長所があります。(そしてもしも大量にあると、読むのが厄介です。)
残念ながら、もしコマンドラインから slon を起動すると、ログ送出構成を含めることを忘れがちで、その結果ログ送出ノードに対するログのシーケンスを破壊します。
コマンドラインオプションが使用される時と異なり、使用中のオプションは可視ではありません。これらは名前、および・もしくは slon 構成の内容から推測され、構成ファイルに後から加えられた変更は反映しません。
いかなるオプションをも含めることを忘れないように、ファイルにオプションを書くことによって、 ログ送出に対してより間違いが無くなります。
ノードをサブスクライブする時に行うこと
新規ノードが大規模なレプリケーションセット(例えば ー サブスクライブに数時間掛かるような)に対し COPY_SET 事象を実行している時、新規サブスクライバから slony ユーザを除いて全てのユーザをロックすることが望ましいことが判っています。その理由は以下のようです。
アプリケーションは完全一貫していない、部分的に複製され、生焼けのデータを扱うようになります。
アプリケーションが(そして保守スクリプトが)システムをデッドロック状態にする問い合わせの組合せを発行し、その結果として、COPY_SET 事象を停止し、サブスクリプションを再度開始を必要とします。
データの複製中は PostgreSQL の fsync 機能を停止することを検討する価値がありそうです。と言うのは、性能の向上に繋がり、COPY_SET 事象の最中にデータベースが"横倒し"になれば全てのレプリケーションセットの複製をやり直さなければならないからです。
slonik 使用の管理
Slonik を使うの注釈で、大量の slonik スクリプトを管理することから学んだ教訓が書かれています。
巨大なレプリケーションセットの取扱い
どこかのユーザが数 10 から数 100 ギガバイトの容量があるレプリケーションセットに対しレプリケーションを設定、それにより、特に COPY_SET 事象が完了するまでに数日掛かるといった、システム上でなんらかの"ひずみ"を生じさせてしまいました。このような情況に対処するため、守るべき原則がいくつかあります。
COPY_SET 事象が実行されている間、主キー以外の全てのインデックスを消去します。
インデックスが張られているテーブルにデータが複写される場合、PostgreSQL は大急ぎで増加的にインデックスを構築します。これは単にデータをテーブルに複製することに比べかなり遅く、後者では、"無から(ex nihilo)"それぞれのインデックスを再構築し、なお、ソートメモリを実質的によく利用できます。
将来のリリースでは、この問題を回避するためインデックスは自動的に削除され、そして再構築されるようになることを希望しています。
大規模なセットが複写されている時、大量の更新が引き起こると、ものすごい数の SYNC 事象によりサブスクライバは裏に持ってゆかれます。
1 秒に 1 度 SYNC が生成されるとすると、1 日あたり約 90,000 SYNC もサブスクライバは"裏に持って行かれ"ます。
関連して、sl_log_1 と sl_seqlog の莫大な肥大化があります。残念なことに、ひとたびCOPY_SET が完了した時点で、それらのテーブルに対する問い合わせが Seq Scans に戻ることを止めず、事象を処理している特定の SYNC が 90,000 SYNC の数少ないの事象を処理しているだけであっても、テーブル全体に渡り依然として読み込みを行っていることに気がつきます。この様な場合、レプリケーションは絶対に追い付きません。
slon パラメータの注意深い選択に係わる、役立ついくつかのことが行えます。
サブスクライバの slon 上で、進行中の SYNC 事象のかなりの量の部分を処理できるようなある値の slon_conf_sync_group_maxsize パラメータにより、一緒に処理される SYNC 事象の数を増加させます。
サブスクライバの slon 上で、適用型 SYNC グループ化システムが小さなグループで開始され、これらの情況下で動きが遅くなるよう、desired_sync_time を 0 に設定します。
オリジンの slon 上で、slon_conf_sync_interval を増加させ、SYNC 事象が頻繁に生成されないようにします。もし SYNC が 1 秒に 1 回ではなく、1 分に 1 回のみ生成されれば、係数 60 で事象の数を減らすことができます。
vacuum スクリプトを実行するのに slon 先導の vacuum を非活性化するため、slon_conf_vac_frequency を使用することは意味がありそうです。と言うのは、データが複写され、サブスクライバが追い付きを開始する間、消去のできないデータの形成があるからです。