- 自鯖の状況
- 1st Server
- 1st@Apps::Apache
- 1st@Apps::MYSQL
- 1st@Apps::PostgreSQL
- 1st@Apps::W2Ch利用状況
- 1st@Apps::W2Chセッション数
- 1st@Apps::iptables
- 1st@Sensor::CPU温度
- 1st@Sensor::FAN回転数
- 1st@System::CPU
- 1st@System::CPU-0
- 1st@System::CPU-1
- 1st@System::CPU-2
- 1st@System::CPU-3
- 1st@System::LoadAvg
- 1st@System::Memory
- 1st@System::Process
- 1st@System::SWAP
- 1st@System::Uptime
- 1st@System::Users
- 1st@Traffic::Ether0
- 1st@Traffic::PPP0
- 1st@Traffic::Wlan
- iptables::ログ集計
- 1st Server
PostgreSQL::Slony実験
# 関連するドキュメント類は読んでいません(^^;
必要に迫られて、こんなテストをやってみました。
Slonyで同期を取っているテーブルに対して、カラム追加・削除を実施。
環境:Master(M)、Slave(S)とします
パターン1:Masterへのカラム追加
実験1:Mのみカラム追加し、Mに対して、データ更新を実施
結果1:Sの該当レコードが更新される(追加カラムは当然無い)
実験2:実験1の直後に、Sへカラム追加
結果2:Sの該当レコードの追加カラムは、変更無し(デフォルト値)
実験3:実験2の直後に、Mの該当レコードを再更新
結果3:Sの該当レコードが更新される(追加カラムも含む)
パターン2:Slaveへのカラム追加
実験1:Sのみカラム追加し、Mに対して、データ更新を実施
結果1:Sの該当レコードが更新される(追加カラムはデフォルト値)
実験2:実験1の直後に、Mへカラム追加し、、該当レコードを再更新
結果2:Sの該当レコードが更新される(追加カラムも含む)
パターン3:Mへのカラムの削除
実験1:Mのみカラム削除、該当レコードを更新
結果1:Sは、削除されたカラムは変更無し、それ以外は、更新される
パターン4:Sへのカラムの削除
実験1:Sのみカラム削除、Mの該当レコードを更新
結果1:Sは、正常に更新される
結論
Slonyはよくできていますね。サービス停止をせずとも、カラム追加が行えます。
しかし、データ同期は、更新が発生した都度となる為、両方に対してカラム追加後に、
データを追加させないと、追加・削除された部分の同期ずれが発生することが判明しました。

