14. データベーススキーマ変更 (DDL)

データベーススキーマに変更が加えられるとき、例えば、テーブルにフィールトの追加を行うなど、より注意を払って処理するべきです。さもないと、どのように特定のテーブルが作成されたかの解釈が一致しないため、異なるノード間で混乱が多少起こります。

EXECUTE SCRIPT (slonik) /schemadocddlscript( integer, text, integer ) (ストアド関数)で変更を Slony-I に伝えるのであれば、全てのノード上のトランザクションストリームの中の同一時に変更が有効になることを確信して構いません。スキーマの変更を行うのに、機能停止の何かを選べるのであれば事はさほど重要ではありませんが、トランザクションがシステムを通して未だ曲がりくねって進んで行く途中で更新をしたい場合、これは必要です。

スキームを変更するために ALTER TABLE を行うのであれば、EXECUTE SCRIPT を使用する必要があります。そうでなければ、 こので説明されている、変更されたテーブル上のトリガがスキーム変更を考慮しないと言う問題に遭遇します。

EXECUTE SCRIPT について "特別なこと"に 2、3 の解説を書く価値があります。

残念なことに、これはそれでもなお、DDL 機能の使用はなんとなく脆弱で、かなり危険であることを意味しています。杜撰かつ無頓着なやり方で DDL の変更を決してしてはいけません。もし、アプリケーションが適切な安定した SQL スキーマを所有していない場合、レプリケーションのために Slony-I を使用することは、問題と失敗を含んだ危険に満ちたものになります。関係する問題点についての論議は ロックの問題 の節を参照してください。

ここに、Varlena General Bits Slony-I スキーマ変更管理をどうするかについての記事があります。

14.1. EXECUTE SCRIPT を使用して処理を望まない変更

レプリケートされているテーブルに対する DDL 修正を伝播するため EXECUTE SCRIPT を使用することが絶対不可欠である限り、何らかの別の方法で処理をしたいと考えるいくつかの種類の変更があります。

14.2. DDL 変更のテスト

DDL 変更のテスト方法はおそらく"最上の練習"と指摘されています。

DDL スクリプトをテストするには非破壊手法が必要です。

理由の如何に係わらず、問題点は、もしノードが全く同期せず、レプリケーションがフェイルオーバしそうになり、最も支障のある時間の一つの中で発生する、つまり、動かしたいと思った瞬間です。

それぞれのノードに対して手作業で最初に BEGIN; を、最後に ROLLBACK; を追加し、スキーマスクリプトが旨く動作するか否かを、あるべきロールバックの変更を本当に検証する必要があります。

全てのノードでこのスクリプトが動作するのであれば、 Slonik で実行したとしてもあらゆる場所で動作するであろうことを暗示しています。いくつかのノードで問題に遭遇したとしても、スクリプトがエラー無しで走り得るためにそれらのノードで事態の状態を自身でできれば修正することです。

警告

もし SQL スクリプトの ROLLBACK; の前の何処かに COMMIT; が含まれていると、予測不可能な変更を容認することになります。