19. Slony-IPostgreSQL のアップグレードに使う

数多くの人々は PostgreSQL のメジャーリリース間でのアップグレードを行う手だてとして、実質的な運転停止期間(例えば、新規データベースインスタンスの作成に必須の initdb の実行)を必要としない、 Slony-I の使用が有用であることを見出してます。

このようなアップグレードを実施するにおいて"簡易な"方法を想像すると、旧バージョンで稼働しているデータベース上で pg_dump を実行し、新規バージョンで実行されているデータベースインスタンスに psql セッションで接続し、結果を転送することでしょう。残念ながら、開始から終了までに消費される時間は、この方式では致命的です。数多くのインデックス付きの 40GB のデータを含むデータベースでは、必要とされる行程は以下のようになります。

これで 40 時間の停止期間になることを覚えてください。

Slony-I はその長期の停止期間を数分、さらには数秒に短縮する機会を提供します。採用する手法は、新規バージョンに Slony-I レプリカを作成するものです。レプリカ作成に 40 時間以上掛かることもあり得ますが、一度作成されれば何時でも最新の状態を保てます。

新規データベースに切替える時点で、この手順は時間消費を少なくします。

この手順はほんの少しの時間を取る必要があるだけで、他は何でも、アプリケーションの再構成にどれだけ迅速に取り掛かれるかに、より向かえる様になります。全ての処置を自動化する事もでき、この場合 1 秒以下になるでしょう。そうでなくとも、数分数秒間の中でのいずれかでしょう。

オリジンが切替えられた後、更新はデータベースに流れる事を覚えておいてください。もし何らかの予測できず、テストが行われなかった情況で、この事に気がついた場合、アプリケーションは新規データベースに接続するという好ましくない結果になります。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リリースでサポートされることは期待されません。