いまさら聞けないPostgreSQL運用管理

いまさら聞けないPostgreSQL運用管理

アップタイム・テクノロジーズ

永安悟史

2012.5.24

Copyright 2012 Uptime Technologies LLC, All rights reserved. 1

自己紹介
• 永安悟史（ながやすさとし）

• 略歴
– 1997年よりインターネットベンチャーにてネットサービス開発・運用に従事。
– 2004年より（株）ＮＴＴデータにて、並列分散データベースの研究開発、技術支援・保守
サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げ、
サービス運用などに従事。
– 2009年、アップタイム・テクノロジーズを創業。

• 専門分野
– データベースシステム、並列分散システム、クラスタシステム
– オープンソース・インフラ技術
– ＩＴサービスマネジメント（ITIL）、ITインフラ運用管理（運用設計～運用）

• 本業＠アップタイム・テクノロジーズ
– オープンソース導入サポートサービス
– データベース・コンサルティング
– ＩＴサービスマネジメント・コンサルティング


DevsとOpsを経験してみて
• 運用担当者こそ技術的知識を
– データベースの運用管理は特に難しい
– 非計画停止はもとより、データロストは致命的

• プロジェクト管理や要件定義の甘さが運用に跳ねる
– バッチ処理
– バックアップ・リカバリ（可用性）設計
– メンテナンス設計

• 「運用でカバー」と言わせないために
– 基盤設計時・運用設計時に「合理的なツッコミ」をできるか？
– 適切なタイミングで適切なツッコミを入れられるスキルを


いまさら聞けないPostgreSQL運用管理
アジェンダ
（1）アーキテクチャ概要

（2）初期設定

（3）データベースの監視

（4）パフォーマンス・チューニング（概論、SQL編、GUC編）

（5）バックアップ・リカバリ（概論、PITR、運用）


（1）アーキテクチャ概要


実行中のプロセス
$ ps -aef | grep postgres
postgres 22169 1 0 23:37 ? 00:00:00 /usr/pgsql-9.0/bin/postmaster -p 5432 -D
/var/lib/pgsql/9.0/data
postgres 22179 22169 0 23:37 ? 00:00:00 postgres: logger process
postgres 22182 22169 0 23:37 ? 00:00:00 postgres: writer process
postgres 22183 22169 0 23:37 ? 00:00:00 postgres: wal writer process
postgres 22184 22169 0 23:37 ? 00:00:00 postgres: autovacuum launcher process
postgres 22185 22169 0 23:37 ? 00:00:00 postgres: archiver process archiving
00000001000000D60000004E
postgres 22187 22169 0 23:37 ? 00:00:00 postgres: stats collector process
postgres 23436 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE
waiting
postgres 23437 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE
waiting
postgres 23438 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] COMMIT
postgres 24283 22169 5 23:45 ? 00:00:02 postgres: postgres postgres [local] idle
postgres 24301 22169 0 23:45 ? 00:00:00 postgres: postgres postgres [local] idle
postgres 24581 22169 0 23:45 ? 00:00:00 postgres: autovacuum worker process
pgbench
postgres 24527 22185 0 23:45 ? 00:00:00 cp pg_xlog/00000001000000D60000004E
/var/lib/pgsql/9.0/backups/archlog/00000001000000D60000004E
$


実行中のデータベースクラスタ（ディレクトリ）
# ls -l
total 116
drwx------ 10 postgres postgres 4096 Dec 14 19:00 base
drwx------ 2 postgres postgres 4096 Jan 10 00:28 global
drwx------ 2 postgres postgres 4096 Dec 13 08:40 pg_clog
-rw------- 1 postgres postgres 3768 Dec 14 15:50 pg_hba.conf
-rw------- 1 postgres postgres 1636 Dec 4 13:47 pg_ident.conf
drwx------ 2 postgres postgres 4096 Jan 10 00:00 pg_log
drwx------ 4 postgres postgres 4096 Dec 4 13:47 pg_multixact
drwx------ 2 postgres postgres 4096 Jan 8 10:14 pg_notify
drwx------ 2 postgres postgres 4096 Jan 10 15:43 pg_stat_tmp
drwx------ 2 postgres postgres 4096 Dec 28 14:41 pg_subtrans
drwx------ 2 postgres postgres 4096 Dec 4 14:47 pg_tblspc
drwx------ 2 postgres postgres 4096 Dec 4 13:47 pg_twophase
-rw------- 1 postgres postgres 4 Dec 4 13:47 PG_VERSION
drwxr-xr-x 3 postgres postgres 4096 Jan 10 15:40 pg_xlog
-rw------- 1 postgres postgres 18015 Dec 14 15:50 postgresql.conf
-rw------- 1 postgres postgres 17952 Dec 14 15:05 postgresql.conf.orig
-rw------- 1 postgres postgres 71 Jan 8 10:14 postmaster.opts
-rw------- 1 postgres postgres 49 Jan 8 10:14 postmaster.pid
#


PostgreSQLの構成要素
PostgreSQLは、さまざまなプロセス・メモリ領域・ファイルによって構
成されている。

writer
postgres logger wal writer autovacuum
（バックグラウンド
（リスナプロセス）（サーバログ）（WALライタ）（自動vacuum）
ライタ）
プロセス群
archiver stat collector postgres wal sender wal receiver
（WALアーカイバ）（統計情報収集）（サーバプロセス）（レプリケーション）（レプリケーション）

shared_buffers wal_buffers visibilitymap freespacemap トランザクション
メモリ群（共有バッファ）（WALバッファ）（ブロック情報）（空き領域情報）制御情報

ファイル群テーブルインデックストランザクションアーカイブ
設定ファイル
ファイルファイルログファイルログファイル


PostgreSQLの基本的なアーキテクチャ
共有バッファを中心として、複数のプロセス間で連携しながら処理を
行うマルチプロセス構造。

postgres
（リスナプロセス）

（

shared_buffers
postgres 共
postgres 有
（サーバプロセス）バ
postgres
（サーバプロセス）
クライアントッ
（サーバプロセス）フ
ァ
）
writer
（バックグラウンド
ライタ）
wal writer
（WALライタ）

テーブル
ファイル
トランザクションインデックス
ログファイルファイル


データファイルの配置
データベースクラスタ（PGDATA）領域

システムカタログ（global）
設定ファイル
テーブルファイル
テーブルファイル (postgresql.conf, pg_hba.conf)

インデックスファイル
インデックスファイルその他制御ファイル等

デフォルトテーブルスペース（base）トランザクションログ（pg_xlog）
ユーザデータベース（OID）


外部テーブルスペース
外部テーブルスペースアーカイブログ領域
テーブルスペース領域

54.1. データベースファイルのレイアウト http://www.postgresql.jp/document/9.0/html/storage-file-layout.html

（2）初期設定


PostgreSQLの設定
• カーネルパラメータ
– 共有メモリ、セマフォの設定
– ハードウェアのスペックによっては、デフォルトのままではPostgreSQL起動
時にエラーとなる

• postgresql.conf
– PostgreSQLパラメータ設定ファイル
– initdbコマンドでデータベースクラスタを作成すると生成される

• pg_hba.conf
– ホストベースアクセス認証（HBA）設定ファイル
– 接続元のホスト情報（IP）を使ってアクセス制御を行う


postgresql.confで設定できる項目
• 共有バッファ

• WALバッファ

• ワークメモリ（ソートメモリ）

• チェックポイント

• バックグランドライタ

• 自動VACUUM


共有バッファ、WALバッファ、ワークメモリ
• 共有バッファ
– テーブルやインデックスなどのデータファイルをブロック単位でキャッシュしておく共有メ
モリ内の領域。
– shared_buffersパラメータで指定。
– 数GB程度から始め、キャッシュのヒット率を見ながら調整を行う。

• WALバッファ
– WALレコードをディスクに書き出す前にバッファリングされる共有メモリ内の領域。
– wal_buffersパラメータで指定。
– トランザクションがCOMMITされるとフラッシュされる。
– 同時実行トランザクションが多い場合、または長いトランザクションが多い場合には大
きめに設定（16MB、32MBなど）。

• ワークメモリ（ソートメモリ）
– SQLでソート処理を行う際にメモリ内でソートを行える上限値（デフォルトは1MB）。
– work_memパラメータで指定。
– EXPLAIN ANALYZEで「Sort Method: external merge Disk: ????kB」が頻発し、パ
フォーマンスが悪化している場合は増加（同時実行数とメモリ使用量に注意）。
第18章サーバの設定 http://www.postgresql.jp/document/9.0/html/runtime-config.html

postgresql.conf
• 必ず変更すべき項目（パフォーマンス関連）
– shared_buffers
– checkpoint_segments
– checkpoint_timeout
– wal_buffers

• 必ず変更すべき項目（バックアップ・リカバリ関連）
– wal_level
– archive_mode
– archive_command
– archive_timeout

• 変更を推奨する項目
– log_line_prefix
– log_filename

• 確認・変更を推奨する項目
– max_connections
第18章サーバの設定
– log_min_duration http://www.postgresql.jp/document/9.0/html/runtime-config.html

pg_hba.conf
• 認証を行うための6項目を1エントリ1行として記述する。

• 接続方法
– local, host, hostssl, hostnossl
• データベース名
– all, <データベース名>
• ユーザ名
– all, +<グループ名>, <ユーザ名>
• 接続元IPアドレス
– 192.168.0.0/255.255.255.0 など
• 認証方法
– trust, md5, password, ident, pam, krb5, ldap, 等

# "local" is for Unix domain socket connections only
local all all ident
# IPv4 local connections:
host all all 127.0.0.1/32 ident
# IPv6 local connections:
host all all ::1/128 ident

19.1. pg_hba.confファイル http://www.postgresql.jp/document/9.0/html/auth-pg-hba-conf.html

（3）データベースの監視


なぜ「監視」が重要なのか？
• PDCA（Plan-Do-Check-Action）を回すため
– データベースがきちんとサービスを提供しているか？
– 性能レベルが落ちていないか？

• 監視は「Action」につなげるための「Check」
– チューニングを行う
– ハードウェアの増強を行う
– メンテナンスを行う

• 「何のために、何を監視するのか」
– あらかじめ決めておくことが重要


OSパフォーマンス監視
• vmstat
• iostat
• mpstat
• sar
• ps
• free


データベースの何を監視するのか？
• SQLパフォーマンス監視
– セッション数
– キャッシュヒット率
– ディスクI/O

• ディスク領域監視
– データ領域（テーブルスペース）、オブジェクトサイズ
– トランザクションログ領域
– アーカイブログ領域

• サーバログ監視
– FATALログ、ERRORログ、WARNINGログ、LOGログ

• システムリソース監視
– CPU、メモリ、ネットワーク、ディスク、プロセス・・・


PostgreSQL内部の監視項目
• オブジェクトサイズ
– データベースサイズ
• pg_database_size()関数
– テーブルサイズ
• pg_relation_size()関数、pg_total_relation_size()関数

• トランザクション量（論理I/O）
– コミット数、ロールバック数（データベース単位）
– INSERT/UPDATE/DELETE数（テーブル/インデックス単位）
• pg_stat_databaseビュー、pg_stat_user_tablesビュー、pg_stat_user_indexesビュー

• ディスクI/O量（物理I/O）
– ブロック読み込み、キャッシュ読み込み（データベース単位）
– ブロック読み込み、キャッシュ読み込み（テーブル/インデックス単位）
• pg_statio_user_tablesビュー、pg_statio_user_indexesビュー

• セッション情報
– pg_stat_activityビュー

• ロック情報
– pg_locksビュー


監視結果の可視化
• サンプルWebアプリを数日間実行し、その間のトランザク
ション数およびデータベースサイズを計測

データベースサイズとトランザクション数

740 1200
720

トランザクション数（TPM）
1000
700
DBサイズ（MB）

800
680
660 600
640
400
620
200
600
580 0
2006/5/4 2006/5/5 2006/5/6 2006/5/7

※PostgreSQL 8.1で計測

全体の傾向を可視化する
• pg_statinfo/pg_reporterを使って、アクセス統計情報を可視化する。
– データベース統計情報
– ディスク使用状況
– テーブル統計情報
– チェックポイント情報
– Autovacuum実行状況
– SQL文実行状況
– 等・・・

pg_statsinfo: Project Home Page
http://pgstatsinfo.projects.postgresql.org/


（4）パフォーマンスチューニング（概論）


パフォーマンスは何で決まるか？
• 「単一クエリのレスポンス×クエリの同時実行数」
– 単一クエリのレスポンス
• サーバ・クライアント間通信（ネットワーク）
• SQLの構文解析、最適化（CPU処理）
• ロックの競合（ロック待ち、デッドロックの発生）
• テーブル、インデックス、ログへのI/O量（ディスクI/O）
• ソート、結合などの演算処理（CPU処理、ディスクI/O）
– クエリの同時実行数
• 接続クライアント数（いわゆるWebユーザ数）
• コネクションプール接続数

• 全体としてハードウェアのキャパシティの範囲内であるか？
– ネットワーク、ディスクI/O、メモリ、CPUなどがボトルネックとなり得る。
– ただし、ボトルネック自体は「結果」であり、「原因」ではない。
– 「なぜ、それがボトルネックになっているのか？」が重要。
• テーブル設計？ SQL文？同時接続数？ HW？設定パラメータ？・・・


データベースを構成するハードウェアリソース
• 複雑な構造を持つRDBMSでは、ボトルネックはいたるところに発生し得
るため、まずはきちんと切り分けることが重要。
– いきなりパラメータチューニングとかを始めない。
CPUネック？
ソート？スキャン？
CPU

ネットワーク
インターフェースメモリロック待ち？
ネットワーク？
プロセス空間

プロセス空間共有メモリ

プロセス空間

スワップ発生？ディスクキャッシュ読み込み？書き込み？
テーブル／インデックス？
トランザクションログ？
ディスクソート？

ディスク
データベースサーバ


パフォーマンス問題の切り分け
• データベースの構成要素ごとに分解していく
ﾌｧｲﾙｼｽﾃﾑパーサ
ボトルネック sys
実行負荷ｵﾌﾟﾃｨﾏｲｻﾞ
user
CPU 実行回数ｴｸﾞｾﾞｷｭｰﾀ
io wait
I/O量
idle
ディスク性能
メモリスワップ
ディスク性能
WAL WAL生成量
共有バッファ
ディスクデータ読み
データサイズ
その他
bgwriter
書き
デッドロック checkpoint 回数
ロック
その他書き出し量

その他ネットワーク

パフォーマンス改善の基本手順
• 全体のパフォーマンスの傾向をつかむ
– どのデータベース、テーブルへのアクセスか？ HWの利用状況はどうか？
– どのメトリックスとどのメトリックスが相関があるか？

• 遅いSQL文を特定する or 実行回数の多いSQLを特定する
– log_min_durationオプション
– pgFouine

• 特定のSQLだけが遅い場合・・・
– SQLのクエリプランおよび実行状況を確認する（EXPLAIN）

• 遅いSQLが特定されない（偏りがない）場合・・・
– ハードウェアリソースのボトルネックを探す

• 対策を実施する
– SQL文を書き換える、インデックスを張る、テーブル設計を修正する
– アプリケーションを修正する
– ハードウェアを増強する
– 他・・・


（4）パフォーマンスチューニング（SQL編）


SQLパフォーマンス分析
• pgFouineによる問題SQL文の抽出、ランキング作成
– 総実行時間＝レスポンスタイム（実行時間）×実行回数
– 最長レスポンスタイム
– 他・・・

pgFouine - a PostgreSQL log analyzer
http://pgfouine.projects.postgresql.org/


SQLクエリ文字列の生成方法の問題

• アプリケーションコードでSQL文を作成する際、指定する条
件に応じてFROM句やJOINを最適化する必要がある。

• アプリ内で文字列を連結してSQL文を生成しても、必ずしも
パフォーマンスのよいSQL文が作成されるとは限らない。

• （例）使われていないテーブルのJOINとソート、等


SQLチューニング（例）

• 無駄なJOINをなくす
– 使っていないテーブル（特に詳細テーブルB）のJOINを排除し、最小
限のリソース（メモリ）で処理を行う。
– 詳細テーブルBだけでも500MB以上あるので、不用意にJOINしてい
てはメモリがいくらあっても足りない（上限はwork_memで設定。上
限を超えるとディスクを使う）。

• LIMITを使用して、ソート時のデータ量を抑制する
– 可能な限り（集約系以外は基本的に）LIMITを使用する。
– サブクエリでLIMITをかける（最初のJOINをする前にデータ量を抑
制）。

• インデックスを作成、インデックスが効くクエリに書き換える


SQLチューニング結果（例）
• 一部クエリについてはパフォーマンスが改善された。
（以下は、ディスクキャッシュが効いていない状況下で測定）
SQLチューニング結果

40

35

30
実行時間（秒）

25
Before
20 Tuned 1
Tuned 2
15

10

5

0
Query 1 Query 2 Query 3

• テーブル設計によってはパフォーマンス向上を実現できない場合もある。

SQLチューニングチェックシート
• 各テーブルのテーブル定義、インデックス定義、レコード件数は確認でき
ていますか？
• PostgreSQL のバージョンはいくつですか？ postgresql.conf の内容は
確認できますか？
• 重いSQL は特定できていますか？
• 重いSQL はどのような実行プランになっていますか？
• 大きなシーケンシャルスキャン、ソートはありませんか？
• 想定していないスキャン、ソートが実行されている場合
• インデックスが使われていない場合
• インデックスが使われている場合

• 「もうダメ！」と思ったときは（でも、できればそうなる前にｗ）
弊社「オープンソース導入サポートサービス」へご相談ください
http://www.uptime.jp/go/oss

SSDを導入してみると・・
Query Execution Time

HDD SSD

16,000

14,000

12,000
Elapsed Time (seconds)

10,000

8,000

6,000

4,000

2,000

0
2

9

6

8

3

4

1

5

7
1
14

20

17
18

21

13

22

16

11

15

10

19

12

2
AD

Q

Q

Q

Q

Q

Q

Q

Q

Q
RF

RF
Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q

Q
LO

DBT-3 Queries

OSDL DBT-3によるPostgreSQLの性能評価（SATA HDD＆SATA SSD編）
http://www.uptime.jp/ja/resources/techdocs/2012/05/pgsql_dbt3_hdd_ssd/

（4）パフォーマンスチューニング（GUC編）

※GUC（Grand Unified Configuration）
PostgreSQLのパラメータ管理モジュール。postgresql.confで設定・管理する。

パラメータチューニング（例）
• shared_buffers
– checkpoint_segments=3固定
共有バッファサイズとpgbenchスコア
(checkpoint_segments=3)

300

290

280
pgbenchスコア（tps）

270

260

250

240

230

220

210
1000 2000 4000 8000 16000 32000 64000
shared_buffers設定値


• checkpoint_segments
– shared_buffers=32000固定

checkpoint_segmentsと性能推移

500

450

400

350

300

250

200

150

100

50

0
1 2 4 8 16 32 64 128
checkpoint_segments設定値


• shared_buffers
– checkpoint_segments=32固定

共有バッファサイズとpgbenchスコア
(checkpoint_segments=32)

500
450

400
350

300
250
200
150
100

50
0
1000 2000 4000 8000 16000 32000 64000
shared_buffers設定値


• バックグラウンドライタ（bgwriter）は、dirtyページを少しずつディスクに
書き戻す

bgwriter無効 bgwriter有効
使用中バッファ dirtyバッファ使用中バッファ dirtyバッファ
18000 18000

16000 16000

14000 14000

12000 12000

バッファページ数
バッファページ数

10000 10000

8000 8000

6000 6000

4000 4000

2000 2000

0 0

24:37.1
24:40.9
24:44.9
24:49.3
24:53.8
24:57.9
25:05.0
25:11.4
25:19.0
25:26.6
25:33.4
25:39.3
25:46.7
25:51.6
25:58.3
26:05.2
26:12.3
26:19.7
27:04.7
27:08.4
27:12.6
27:17.0
27:21.5
27:25.4
27:32.4
27:39.7
27:47.8
27:56.4
28:04.4
28:10.7
28:17.6
28:25.0
28:30.4
28:36.5
28:41.6

時刻時刻

F.24. pg_buffercache
http://www.postgresql.jp/document/9.0/html/pgbuffercache.html

パラメータ設定におけるトレードオフ
• 共有バッファを大きくすると・・・
– より多くのディスクブロックを共有バッファに保持できるため、パフォーマンス
が向上する。
– 大量のdirtyページが発生するため、チェックポイント時の負荷が高くなる。

• チェックポイントの間隔を大きくすると・・・
– チェックポイントの発生数を抑え、パフォーマンスが向上する。
– チェックポイント時の負荷が高くなる。
– クラッシュリカバリに要する時間が長くなる。

• バックグラウンドライタを頻繁に動かす（多く書き出す）と・・・
– チェックポイントにおける負荷は減るが、書き出しのディスクI/Oが頻発する
（書き出しの平準化により）。
– 全体的なパフォーマンスが低下する。（特にディスクが1本の場合）


（5）バックアップ・リカバリ（概論）


バックアップとレストア／リカバリ
• バックアップの難しさ
– データはファイルの中にだけあるのではない
– 通常は、共有バッファの内容が最新
– ファイルだけバックアップを取ってもダメ
– ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で

• バックアップの種類
– コールドバックアップ
– ホットバックアップ
– PITR（アーカイブログ）バックアップ

• バックアップ＆レストア／リカバリはリハーサルをしよう！
– 簡単な試験や手順書を作るだけで満足してはいけない・・・


興行収入5億ドルの “TOY STORY 2” は一度消えかけた

http://www.tested.com/videos/44220-how-pixar-almost-lost-toy-story-2-to-a-bad-backup/

コールドバックアップ
• サーバプロセスをすべてシャットダウンしてデータファイル全体をバックアップ
– バックアップの間、サービス停止が発生する。
– リカバリの際には、バックアップ時のデータに戻る。
– ファイルバックアップなのでレストアが簡単。
• 向いているケース
– 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。
– ストレージスナップショットが一般化した今、案外現実的。
• 向いていないケース
– サービスを停止させられない場合。
– 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。

Crash
①サービス
WAL1 WAL2 WAL3
停止＆ ②障害発生
ファイル
バックアップ
③レストア

Index
Table


ホットバックアップ（pg_dump/pg_restore）
• あるタイミングでデータの一貫性を保ちつつバックアップ（export）
– シンプルかつ柔軟（テーブル単位のバックアップも可）
– バックアップ時にサービス停止は起こらない。
– リカバリの際には、バックアップ時のデータに戻る。
– 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。
– データベース単位、テーブル単位でバックアップを取りたい場合。
– 論理バックアップが必要な場合（メジャーバージョンアップなど）
– 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。

Crash
WAL1 WAL2 WAL3
①pg_dumpで ②障害発生
スナップショットを
バックアップ
③レストア

Index
Table


（5）バックアップ・リカバリ（PITR）


アーカイブログとPITRを用いたバックアップ
• ベースバックアップ（基準点）＋アーカイブログ（更新差分）
– サービスを継続したままベースバックアップを取得可能（非一貫性バックアップ）
– クラッシュ直前のWALの内容まで復旧することが可能
– データベースクラスタ全体の完全なバックアップを取りたい場合。
– クラッシュ直前の更新まで復旧させる必要がある場合。
– データベース単位、テーブル単位などでバックアップを取得したい場合。

Crash
WAL1 WAL2 WAL3 WAL4
①ベースバック
アップの取得
（非一貫性 ②WAL1を ③WAL2を ④WAL3を
バックアップ）アーカイブアーカイブアーカイブ

Index WAL1 WAL2 WAL3
Table
レストア＆リカバリに必要なファイル類

アーカイブログとPITRを用いたリカバリ
• ベースバックアップ（基準点）＋アーカイブログ（更新差分）
– ベースバックアップをレストア後、アーカイブログをロールフォワードリカバリする。
– 前回のベースバックアップ以降、長期間が経過しているとアーカイブログが多くなり、リ
カバリの時間が長くなる。
– ベースバックアップレストア時間＋アーカイブログ適用時間×アーカイブログ数

⑥リカバリ完了

WAL1 WAL2 WAL3 WAL4
①ベース ⑤オンラインWAL
バックアップを ②WAL1を ③WAL2を ④WAL3を（WAL4）を適用
レストア適用適用適用

Index WAL1 WAL2 WAL3
Table
レストア＆リカバリに必要なファイル類

アーカイブログ関連パラメータ
• wal_level
– 生成されるWALレコードの内容を指定する（”minimal”, “archive”, “hot_standby”）
– アーカイブログを取得する場合には “archive” を指定

• archive_mode
– アーカイブログ取得モードを設定する（”on” or “off”）

• archive_command
– オンラインWALファイルをアーカイブするOSコマンド（一般的には cp コマンドなど）
– 'cp %p /var/lib/pgsql/9.0/backups/archlog/%f‘

• archive_timeout
– 使用中のオンラインWALファイルを強制的にアーカイブする秒数を指定
– 更新（WALレコード）が少ない場合などでも、確実にアーカイブしたい場合などに設定

18.5. ログ先行書き込み（WAL）
http://www.postgresql.jp/document/9.0/html/runtime-config-wal.html


ベースバックアップの取得手順と取得対象
• 前提条件
– アーカイブログの設定が有効になっていること

• 取得手順
– pg_start_backup()でバックアップ開始
– データベースクラスタ全体のバックアップを取得
– pg_stop_backup()でバックアップ完了

• 取得対象
– データベースクラスタ全体
– テーブルスペース（使用している場合）
– XLOGファイル（pg_xlog以下）とpostmaster.pidファイルは除く


リストア、リカバリ手順
• PostgreSQLサーバを停止する

• 障害の発生したデータベースを保存する（可能であれば）
– データベースクラスタ
– トランザクションログ（残っている場合は必ず保護する）
– テーブルスペース

• ベースバックアップをレストアする

• ベースバックアップ取得以降のアーカイブログをレストアする

• 最新のトランザクションログを配置する

• リカバリ設定ファイル（recovery.conf）を作成する

• PostgreSQLサーバを起動し、リカバリ処理を実行する

PITRのリカバリ動作状況
[2011-12-12 06:32:52 JST] 31582: LOG: database system was interrupted; last known
up at 2011-12-12 06:12:28 JST
[2011-12-12 06:32:52 JST] 31582: LOG: restored log file "00000002.history" from
archive
[2011-12-12 06:32:52 JST] 31582: LOG: starting archive recovery
[2011-12-12 06:32:52 JST] 31582: LOG: restored log file "000000010000000000000005"
from archive
[2011-12-12 06:32:53 JST] 31582: LOG: redo starts at 0/5000070
[2011-12-12 06:32:53 JST] 31582: LOG: consistent recovery state reached at
0/6000000
from archive
(...snip...)
[2011-12-12 06:33:40 JST] 31582: LOG: restored log file "00000001000000000000000F"
from archive
from archive
(...snip...)
[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000002000000000000001A"
from archive
[2011-12-12 06:34:49 JST] 31582: LOG: could not open file
"pg_xlog/00000002000000000000001B" (log file 0, segment 27): No such file or
directory
[2011-12-12 06:34:49 JST] 31582: LOG: redo done at 0/1A00511C
[2011-12-12 06:34:49 JST] 31582: LOG: last completed transaction was at log time
2011-12-12 06:23:09.691458+09
[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000002000000000000001A"
from archive
[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000003.history" from
archive
[2011-12-12 06:34:49 JST] 31582: LOG: selected new timeline ID: 4


（5）バックアップ・リカバリ（運用）


バックアップ、リカバリの運用
• 指定したサイクルで定期的にベースバックアップを取得
– ベースバックアップスクリプトをcron等で実行し、ベースバックアップを取得
– 世代ごとにサブディレクトリを作ってベースバックアップを保存
– 指定した世代数を超えたベースバックアップを削除
– もっとも古い世代のベースバックアップ以前のアーカイブログを削除

• 障害が発生した場合は、ベースバックアップおよびアーカイブログからリ
カバリ
– XLOGバックアップスクリプトを実行し、オンラインWALファイルを保存
– リカバリスクリプトを実行し、最新のベースバックアップ、およびオンライン
WALファイルをレストアし、リカバリ設定ファイルを作成
– PostgreSQLサービスを起動し、リカバリを実行


ベースバックアップの世代管理
• 指定したバックアップ世代数に合わせて、ベースバックアップとアーカイブログを
管理する
– 最新のベースバックアップを取得できたら、もっとも古いベースバックアップを削除
– アーカイブログは、もっとも古いベースバックアップ以前のものを削除

（例）ベースバックアップを3世代分保持する場合
コピー
データベーススナップショット
クラスタ（一時領域）
アーカイブ、圧縮
第0世代
WAL
Rotate
第1世代
Rotate
アーカイビング第2世代
第0世代を取得後に削除
第3世代

第2世代以降に生成された
アーカイブログ
アーカイブログを保持

バックアップ用ストレージ

リカバリ時の動作
• 最新のWALファイルを保存、最新の世代のベースバックアップからレストアし、リ
カバリ実施に必要な設定ファイルを作成する
– データベースクラスタに残っている最新のWALを保存（①）
– ベースバックアップからレストア（②）
– 最新WALを再度配置（③）
– リカバリを開始したら、アーカイブログを適用（④）

データベーススナップショット
②レストア（一時領域）
クラスタ
第0世代
WAL
第1世代
①最新WAL
保存
第2世代
④適用
③最新
最新WAL
WAL配置

第2世代以降に生成された
アーカイブログ
アーカイブログを保持

バックアップ用ストレージ

Q&A


さらに詳しくなりたい方は
• PostgreSQLアーキテクチャ入門（自習用教材）
– 内容：プレゼンテーションを録画した動画、及び使用しているスライド
– 動画時間：約55分
– スライドページ数：54ページ
– ファイル形式：MP4（動画）およびPDF（スライド）
– 価格：1,050円（税込）

• OSDL DBT-3によるPostgreSQLの性能評価（SATA HDD＆SATA
SSD編）
– 内容：技術検証レポート
– ページ数：54ページ
– ファイル形式：PDF
– 価格：1,260円（税込）

いずれも http://www.uptime.jp から購入できます。


【お問い合わせ先】
アップタイム・テクノロジーズ合同会社
永安悟史
E-mail： snaga@uptime.jp
Web: http://www.uptime.jp/


いまさら聞けないPostgreSQL運用管理

More Related Content

いまさら聞けないPostgreSQL運用管理