数多くの人々は PostgreSQL のメジャーリリース間でのアップグレードを行う手だてとして、実質的な運転停止期間(例えば、新規データベースインスタンスの作成に必須の initdb の実行)を必要としない、 Slony-I の使用が有用であることを見出してます。
このようなアップグレードを実施するにおいて"簡易な"方法を想像すると、旧バージョンで稼働しているデータベース上で pg_dump を実行し、新規バージョンで実行されているデータベースインスタンスに psql セッションで接続し、結果を転送することでしょう。残念ながら、開始から終了までに消費される時間は、この方式では致命的です。数多くのインデックス付きの 40GB のデータを含むデータベースでは、必要とされる行程は以下のようになります。
データの変更を行う可能性のある全てのアプリケーションを停止する。
pg_dump を開始し、新規データベースにロードする。
ダンプとロードが完了するまで 40 時間待機する。
新規データベースに"書き込み"アプリケーションを方向付ける。
これで 40 時間の停止期間になることを覚えてください。
Slony-I はその長期の停止期間を数分、さらには数秒に短縮する機会を提供します。採用する手法は、新規バージョンに Slony-I レプリカを作成するものです。レプリカ作成に 40 時間以上掛かることもあり得ますが、一度作成されれば何時でも最新の状態を保てます。
新規データベースに切替える時点で、この手順は時間消費を少なくします。
データの変更を行う可能性のある全てのアプリケーションを停止する。
LOCK SET を用いてクライアントアプリケーションの更新に対しセットをロックする。
旧データベースから新規データベースにオリジンを移動させるため、Slonik MOVE SET コマンドを発行する。
アプリケーションを新規データベースに向かせる。
この手順はほんの少しの時間を取る必要があるだけで、他は何でも、アプリケーションの再構成にどれだけ迅速に取り掛かれるかに、より向かえる様になります。全ての処置を自動化する事もでき、この場合 1 秒以下になるでしょう。そうでなくとも、数分数秒間の中でのいずれかでしょう。
オリジンが切替えられた後、更新は旧データベースに流れる事を覚えておいてください。もし何らかの予測できず、テストが行われなかった情況で、この事に気がついた場合、アプリケーションは新規データベースに接続するという好ましくない結果になります。MOVE SET を再度使用してオリジンを再度旧データベースに切替え戻してください。
全ての変更を直ちにロールバックできるように、そして同時に旧バージョンに切替えられるように(切替え以降の如何なる更新でも)するために、切替え時点のその状態の旧データベースに切替え戻す事ができるのが特に大切と考えるならば、次のような手順で実現できます。
2 つの Slony-I レプリカを用意します。
ひとつは PostgreSQL の新規バージョンを走らせます。
もうひとつに PostgreSQL の旧バージョンを走らせます。
これで、3 つのノードがあり、1 つで PostgreSQL の新バージョンが稼働し、残りの 2 つで旧バージョンが稼働します。
ひとたびそれらが大まかに"同期状態"になれば、データを変更する可能性のある全てのアプリケーションを停止します。
それらに同期を取らせ、そして PostgreSQL の旧バージョンが稼働しているサブスクライバに供給を続けている slon デーモンを停止します。
この状態をどれほど保持したいか次第で、スタンドアロンのデータベースにするか、もしくは単に slon を中断するため、このノードの運行停止に UNINSTALL NODE を使用したいことがあります。
そうであれば MOVE SET で以前のようにオリジンを切替えます。
"ちょっとした"災難が起こったとして、更新が送られて来るのを待っている旧データベースが稼働しているノードに復旧させたいと考える事もあります。もしより大きな問題に引きずりこまれるようであれば、2 つのノードを放棄して、運転停止していた 1 つのノードを使用します。
このような"偏執症的な"手順が欠かせないこの種の問題を保有するのが日常的であると言っているのではありません。プロセスのリスク評価に悩んでいる人々にとって、このような選択枝は安心を与えます。
注意: Slony-I は 7.3.3 より以前のバージョンの PostgreSQL をサポートしていません。と言うのは名前空間のサポートが必要で、その時点以前ではきちっと実装されていませんでした。Rod Taylor が Slony-I オブジェクトをグローバルスキーマ内に実現できるようにすることで、Slony-I を 7.2 上で動くように"ハック"しました。彼が判ったのは大変扱いにくく、いくつかの問い合わせは非常に効率的ではないことでしたが(PostgreSQL の問い合わせオプティマイザは 7.2 以降ずいぶん改善されました)、この事が他の eRServer の様なレプリケーションシステムより彼をして働きがいのあるものにしました。どうしても必要と考えるのであれば、 PostgreSQL Hackers メーリングリストで彼を探してください。7.2 が如何なる正式な Slony-Iリリースでサポートされることは期待されません。