PostgreSQL よる多版型同時実行制御(MVCC)の使用による通例の長所の 1 つは、これにより、合理的な全てのホストからデータベースオブジェクトにロックを掛ける必要性を省略させることです。他のいくつ化のデータベースシステムでは、テーブルにデータを挿入するためにテーブルロックを獲得しなければならず、それは厳しいほど性能を妨げます。他のシステムでは、書き込みロックは書き込みを妨げます。MVCC によりPostgreSQL は、"古い読み込み"におけるロックの全てのクラスが"古いタプル"にアクセスできるように削除します。殆どの時点で、このことは PostgreSQL の育ちの良いユーザにロックに多大の心配をしなくてもよいようにします。
残念なことに、 Slony-I の構成の変更は、"ロックの苛立ち"のようなことをもたらす結果を伴う、PostgreSQL テーブル上に排他ロックを必ず必要とする数種類の Slony-I 事象があります。特に以下のことがあります。
そのテーブルの更新を収集するトリガーを付加するため、"オリジン"ノード上で暫定テーブルロックが獲得されなければなりません。
セットオリジンが一つのノードから他のノードへ移行されると、そのテーブル上のトリガーを変更するために、旧オリジンと新オリジン双方のテーブル上にロックが獲得されなければなりません。
この操作は特別に、オリジンノード上の与えられたレプリケーションセット内のテーブルにロックを要求します。
この操作はひと続きの SQL 問い合わせを走らせます。これが動作するようにSlony-I トリガーは削除されなければならず、引き続いて問い合わせが行われ(可能性としてはデータの更新)、それに続きトリガーがリストアされます。したがって、操作はそれぞれのノード上の全てのレプリケートされたテーブル上のテーブルロックを獲得しなければなりません。
新規サブスクライバ上での COPY_SET 事象の中で
感覚的に、これは最も挑発的な筋書きです。と言うのは、レプリケーションセットが移植される前に、ノードが"使用不可"となり、そして Slony-I はそのノードへの排他的アクセスを合理的に期待することができる、といったことは非常に無理のない表現です。
これらのそれぞれの行為は、ある時点で、影響を受けたレプリケーションセット内のそれぞれのテーブルの変更を要求し、それはそのテーブル上の排他的ロック獲得を必要とします。アプリケーションを能動的にサービスしている Slony-I ノード上でこれらの操作の稼働を試みたユーザの何人かは、デッドロック、および、もしくは操作のハングアップといった支障を経験しています。
明白な質問:"そのようなデッドロックにどう対処しますか。"
自身が認めるいくつかの可能性
デッドロックを回避するアプリケーション停止の告知
アプリケーションに暫定的にデータベースの使用を中止されることが可能であれば、その間に自己の制御下にある管理プロセスを除いて、データベースに対して何も稼働していない時間的余裕を与えられます。
操作試行、動作することを願って
現在のままに、アプリケーションがアクセスロックをそのままにしておくことを防ぐことはできないため、デッドロックを自ら捜し出さなければならないかも知れません。とは言っても、残っているロックの数が少なければ、ユーザ間で"端と端を接し"、障害克服ができるかもしれません。
pgpool の使用
pgpool もしくは何らかの似通った"接続ブローカ"を使えるのであれば、接続管理プログラムに対してちょっとの間データベースの使用を停止するように伝え、管理プログラムに、代わってアプリケーションを"阻止"させるようにします。何が理想的なことかと言えば、データベースの短い停止が、ユーザとっては物事がゆっくりと進んでいる用に見えるように、接続管理プログラムが少しの間ユーザ問い合わせを阻止することです。
迅速停止管理
以下の手順は停止期間を最小にするかも知れません。
slony ユーザ のみがデータベースにアクセスできるように pg_hba.conf を変更します。
PostgreSQL postmaster に対して kill -SIGHUP を発行します。
既存のひょっとしたら長期間走っている問い合わせは停止できないかもしれませんが、新規の参入は防げるでしょう。これには、到達する問い合わせがプロセスの終了まで排除されるというアプリケーション上の大きな影響があります。
もしも、"全てが良さそう"であれば、Slony-I 操作を前に進めても安全です。
何らかの古い問い合わせが後まで残っているのであれば、PostgreSQL プロセスの 1 つを kill -SIGQUIT する必要があるかもしれません。これでバックエンドを再稼働させ、残っている問い合わせを削除します。ノードに所属した slon プロセスを再稼働させる必要も多分あるでしょう。
ここにおいて、Slony-I 操作を前に進めても安全です。
他のユーザが参加できるように pg_hba.conf をリセットし、セキュリティ構成を再読み込みさせるように postmaster を kill -SIGHUP します。
DDL 変更の節では、ロックされるべきテーブルセットを最小化する方法で、レプリケーションセット間でテーブルを移動させるなど、有用な追加記述を提案しています。
残念ながら、この件に関する完全な回答は存在しません。もしも MOVE SET 要求を提出する必要があれば、それは多分短時間のアプリケーション停止を受け入れる必要があります。Slony-I/ pgpool 連結が改善されるにつれ、この問題を扱うより良い方法になるかも知れません。