「もうMATERIALIZED VIEWの挙動でやきもきしない」 9.4での設定・運用の改善:PostgreSQLガイダンス(2)(4/4 ページ)
PostgreSQL 9.4の新機能のうち、postgresql.auto.confを使った設定変更の方法や、pg_prewarm、 MATERIALIZED VIEWのCONCURRENTLYオプションなど、主にPostgreSQL環境を運用する際に関係する改善点を中心に紹介します。
アーカイブログの状態を見る(pg_stat_archiver)
PostgreSQLは、2005年リリースのバージョン8.0からアーカイブロギングをサポートしています。トランザクションログをアーカイブログとして継続的に保存して、バックアップ/リストアや、レプリケーションに使用できます。
しかしながら、その実現方法・設定方法はいくぶん独特です。以下のように、トランザクションログのファイル(WALファイル)を格納保存するためのコマンドを設定ファイル(postgresql.conf)で指定します。
以下例ではLinux環境標準のcpコマンドを使っています。Windows環境ではcopyコマンドを記述しますし、工夫をこらした独自のコマンドも使えます。「PostgreSQL本体は、アーカイブロギング実現方法の詳細は関知しない」という設計ポリシーになっているのです。
archive_mode = on archive_command = 'cp %p /data/pgsql/archive/%f'
さて、PostgreSQL 9.4から、以下のようにアーカイブロギングの状況をシステムビューpg_stat_archiverで参照できるようになりました。
db1=# SELECT * FROM pg_stat_archiver; -[ RECORD 1 ]------+------------------------------ archived_count | 6 last_archived_wal | 000000010000000000000006 last_archived_time | 2014-08-31 10:30:18.584179-04 failed_count | 3 last_failed_wal | 000000010000000000000005 last_failed_time | 2014-08-31 10:29:41.885038-04 stats_reset | 2014-08-31 07:31:05.472934-04
pg_stat_archiverを使うと図7の実行例のように、アーカイブ成功と失敗の累計数、最後にアーカイブしたファイル名と時刻、最後にアーカイブに失敗したファイル名と時刻が出力されます。累計数は以下コマンドでリセットされ、リセット時がstats_resetカラムに記録されます。
db1=# SELECT pg_stat_reset_shared('archiver');
アーカイブログの状況を見るには、これまではログメッセージやpg_xlogディレクトリのファイルを調べる必要がありましたので、この実装により、運用はぐっと便利になりました。とはいえ、「アーカイブログ格納ディレクトリに現在WALファイルがいくつあるのか?」といった詳細情報は、依然としてPostgreSQL本体機能による管理の対象外です。
テーブルスペースの一括移動
PostgreSQLのテーブルやインデックスは、いずれかのテーブルスペースに格納されます。特に意識していないなら、データベースクラスタディレクトリ内にあるデフォルトテーブルスペースに格納されているはずです。テーブルが格納されているテーブルスペースを変更するには、これまでALTER TABLEコマンドを使って一つずつ移動する必要がありました。インデックスも同様です。
これに対し、PostgreSQL 9.4ではALTER ... ALL IN TABLESPACE ...という、指定テーブルスペースにある全要素をテーブルスペース変更する ALTERコマンドの対象とする構文が追加されます。使い方は図9の通りです。図9の例ではALTER TABLEですが、ALTER INDEXに対しても同様に使えます。
db1=# ALTER TABLE ALL IN TABLESPACE ts_user1 SET TABLESPACE ts_user2;
なお、本構文は9.4 beta2からbeta3にかけて変更されており、beta2では異なる構文でした。
まとめ
さて、いかがでしたでしょうか。派手な新機能はないですが、実際にPostgreSQL 9.3.xを使っているユーザーがいかにも要望として挙げそうな項目が改良されたという印象ではないかと思います。細かなところですが、運用効率の面では大きな改善が行われているといえるでしょう。
次回は、データベースアプリケーションから使われるSQL構文やレプリケーション機能を取り上げます。お楽しみに。
Copyright © ITmedia, Inc. All Rights Reserved.