PostgreSQL8.1 -> 9.3へ移行した際のメモ

postgresql

この記事はPostgreSQL Advent Calendar 2014 25日分となります。

昨日は @_Naofumi_ さんの PostgreSQLにおけるPAXページレイアウトの実装 でした。

さてさて私はというと、今年、運用中postgresqlを8.1から9.3へ移行しました。
移行した際に実施したことや変更したことについての当時の記憶を書きいていきます。

  • データ移行は論理バックアップ pg_dumpall で実施
    • slonyにてマスタDBをスイッチオーバーしてデータ移行する方法も検討したが、8.1と8.3以降でslonyのメジャーバージョンが変わる為、断念＞＜
  • HOTを有効に使用する為、更新が多いテーブルにFILLFACTORを設定
  • slony時にリードレプリカ1台をバックアップ取得専用インスタンスにしていたので、同様にstreaming replicationのslave1台でpg_dumpを走らせる
    • リードレプリカでpg_dump中、長時間のロックがかかると、WALが流れてしまいレプリケーションがアボートすることが判明。
  • リードレプリカ上でpg_basebackupにてバックアップする方針に変更。
    • pg_basebackup中にslave上のWALが流れてしまうとpg_basebackupがこけてしまう事象が発生。
    • pg_basebackup -xを外す運用も考えたが、こちらはこちらでリストアがうまく行かないケースがあった。
      • 詳細は昔のことなので忘れたw
      • 当然のことながら、使えないかもしれないバックアップセットを確実にとるより、極稀に失敗することもあるが使えるバックアップを取得する方針で。
    • バックアップ失敗時は、アラートを通知。
    • ちなみに運用が始まって以来、失敗はまだなし
  • レプリケーションの監視は自作のnagiosプラグインにて
    • select client_addr,state from pg_stat_replication; にて各スレーブホストのstate=streamingの確認
      • WALが流れすぎると、「FATAL: WAL ストリームからデータを受信できませんでした: ERROR: 要求された WAL セグメント xxxx はすでに削除されています」となり、対象のスレーブのレコードは上記クエリの結果から参照されなくなる
    • masterの[wal sender process]の確認
    • slaveは[wal receiver process]の確認
  • Amazon RDS for PostgreSQL にすることも考えたが、当時はまだリードレプリカの機能が備わってなかったので検討から外す。
  • DDLの反映はマスタのみで可能。ちょー楽w

以上となります。

ではでは、みなさん、良いクリスマスをーー。 メリークリスマス（＾ω＾）