PostgreSQLバックアップの基本

PostgreSQLバックアップの基本

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

永安悟史

2012.8.29

Copyright 2012 Uptime Technologies LLC, All rights reserved. 1

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

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

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

• 本業＠アップタイム・テクノロジーズ
– オープンソース導入サポートサービスの提供
– セミナ、トレーニングの提供
– 学習用コンテンツのオンライン販売
– その他、OSSおよびDB系技術コンサルティング


PostgreSQLバックアップの基本
アジェンダ
（1）アーキテクチャ概要

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

（3）バックアップ・リカバリ～ PITR

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

（5）バックアップ・リカバリ～ツール


（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ライタ）

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


メモリ（共有バッファ）
• ディスク上のブロックをキャッシュするメモリ領域
– ディスク上のブロックのうち、アクセスするものだけを読み込む
– ディスクI/Oを抑えて読み書きを高速化
– すべてのサーバプロセスで共有
• 変更されたブロック（dirtyページ）は必要に応じてディスクに書き戻される
– 契機は、「バッファ入れ替え、チェックポイント、バックグラウンドライタ」
– 変更の永続性はトランザクションログで担保する

writer
postgres
9 17 5 14
postgres

postgres 共有バッファ 1 2 3 4 5 6
（メモリ） 7 8 9 10 11 12
サーバプロセス
13 14 15 16 17 18
wal writer
19 ・・・・
トランザクション
ログファイルテーブル／インデックスファイル
Copyright 2012 Uptime Technologies LLC, All rights（ディスク）
reserved. 9

データファイルの配置
データベースクラスタ（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）バックアップ・リカバリ（概論）


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

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

• バックアップ＆レストア／リカバリはリハーサルをしよう！
– 簡単な試験や手順書を作るだけで満足してはいけない・・・
– そのバックアップセットで本当にリカバリできますか？

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

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

Index
Table


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

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

Index
Table


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


用語
• オンラインWALファイル
– pg_xlogディレクトリに配置されている（まだアーカイブされていない）WALファイル

• アーカイブWALファイル（アーカイブログ）
– アーカイブされたWALファイル

• 完全リカバリ
– （オンラインWALファイルを用いて）最新の状態まで戻すことのできるリカバリ

• 不完全リカバリ
– オンラインWALファイルを消失したため、最新の状態ではなく、アーカイブWALファイ
ルまでしか戻せないリカバリ

• ベースバックアップ（非一貫性バックアップ）
– 共有バッファなどの状態に関係なく、ファイルシステムレベルで取得するファイルバック
アップ。
– 「データベースのファイル」として一貫性の取れた内容である保証は無い。


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

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

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

アーカイブWALとPITRを用いたリカバリ
• ベースバックアップ（基準点）＋アーカイブWALファイル（更新差分）
– ベースバックアップをレストア後、アーカイブWALファイルを使ってロールフォワードリカ
バリする。
– オンラインWALファイルが残っていれば、完全リカバリが可能。
– 前回のベースバックアップ以降、長期間が経過しているとアーカイブWALファイルが多
くなり、ロールフォワードリカバリの時間が長くなる。
– 所要時間は、「ベースバックアップレストア時間＋アーカイブWALファイル適用時間」
⑥リカバリ完了

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

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

障害とリカバリのシナリオ
• データベースクラスタ（テーブルスペース）領域のロスト、障害
– ベースバックアップからデータベースクラスタをレストアし、アーカイブログを
用いてリカバリをする必要がある。
– オンラインWALファイルが残っている場合には「完全リカバリ」が可能。

• オンラインWAL領域のロスト、障害
– PITRによるリカバリは「不完全リカバリ」となる。完全リカバリは不可。
– PostgreSQLが起動しなくなる可能性が高いため、ベースバックアップ＋アー
カイブWALからリカバリを実施（不完全リカバリ）。

• アーカイブWAL領域のロスト、障害
– アーカイブWAL領域の障害は、サービスにはすぐには影響しない。
– 但し、アーカイブが失敗し始めると、オンラインWAL領域を圧迫し始める。そ
のため、アーカイブを再開できるよう、アーカイブWAL領域を復旧させる必要
がある。
– また、障害が発生した際には、ベースバックアップ以降のすべてのアーカイブ
WALファイルがないとリカバリできないため、再度、ベースバックアップを取
得する必要がある。


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

• 障害の発生したデータベースを保存する（可能であれば）
– データベースクラスタ
– テーブルスペース
– オンラインWALファイル（残っている場合は必ず退避しておく）

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

• ベースバックアップ以降のアーカイブWALファイルを、アーカイブWAL領
域にレストアする

• 退避しておいたオンラインWALファイルを配置する

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

• PostgreSQLサーバを起動する（リカバリ処理は自動実行される）


リストア、リカバリ概念図
• ベースバックアップ、アーカイブWALファイル、オンライン
WALファイルを用いてリカバリを行う。

通常稼働時リカバリ時
②アーカイブWALで
リカバリ
②③
ログ適用
③オンラインWAL
でリカバリ

Table WAL WAL Table WAL WAL

Index Index
アーカイブWAL アーカイブWAL
障害発生リカバリ対象
データベース ①データをデータベース
レストア

Table Table

Index Index

ベースバックアップベースバックアップ

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


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


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

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


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

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

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

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

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

データベーススナップショット
②レストア（一時領域）
クラスタ
第0世代
WAL

①オンライン第1世代
WAL保存
第2世代
④適用
③オンライン最新WAL
WAL配置

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

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

アーカイブWALファイルの消し込み
• ベースバックアップを取得すると、そのベースバックアップより前のアーカイ
ブWALファイルは不要になる
– 具体的には ”START WAL LOCATION” より前のWALファイル
– ベースバックアップ②を取得したら、アーカイブWAL①は不要
– 但し、世代管理は必要

アーカイブWAL① アーカイブWAL②

WAL WAL WAL WAL WAL WAL WAL WAL

ベースベース
バックアップ① バックアップ②

• 消し込みの方法
– pg_archivecleanupコマンドを使う（contribモジュール）
– tmpwatchでタイムスタンプで判断（24時間以上経過したら削除、等）


（5）バックアップ・リカバリ（ツール）


pg_rman
• NTT OSSセンターの開発したPostgreSQLバックアップツール
– バックアップの取得
– リストア／リカバリの実行
– バックアップセットの管理
– D2D （Disk to Disk）のツール

• 運用方法
– バックアップ取得（full、incremental、archive）
– バックアップ検証（validate）
– バックアップ消込（delete）
– レストア／リカバリ実施

pg-rman - PostgreSQL Recovery Manager - Google Project Hosting
http://code.google.com/p/pg-rman/


Barman
• 2ndQuadrantの開発したPostgreSQLバックアップツール
– バックアップの取得（複数サーバ、ネットワーク経由）
– リストア／リカバリの実行
– バックアップセットの管理
– D2D （Disk to Disk）のツール
– 複数サーバを対象としたバックアップ管理が可能

Barman - Backup and Recovery Manager for business critical PostgreSQL databases
http://www.pgbarman.org/


Q&A


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

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

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


PostgreSQLパフォーマンスチューニング入門
• 日時：2012年9月14日（金） 14:30～17:30 （約3時間）
• 場所：クロスコープ青山セミナールーム（東京メトロ外苑前駅）

• 概要
– PostgreSQLを利用する際に必要となるパフォーマンス管理およびチューニングについて、その仕組み
や手順などの基本的な知識を獲得することを目的とします。

• 対象
– PostgreSQLを使っているアプリケーション開発者の方
– PostgreSQLをこれから使い始めるデータベース管理者の方
– 現在、他のRDBMSを使っており、今後のPostgreSQLの利用を検討している方
– PostgreSQLを使っているがパフォーマンス問題に困っている方

• 前回の参加者の皆さまからのコメント（アンケートより）
– 丁寧な内容で構築・運用時に押さえるべき点を把握できた
– 各パラメータについてはある程度知っていたが体系的に学ぶことができた
– ツールや分析方法に知らないことが多かった
– 全体のアーキテクチャの説明により、チューニングの基本が納得できた

• 詳細
– http://bit.ly/MgYKPB


アップタイム・テクノロジーズについて
• オープンソース導入サポートサービスの提供
– 各種OSS（ミドルウェア、ツールなど）についての調査・情報提供
– 設計（基盤～アプリ）、開発の支援
– 機能検証・性能見積もり支援（機能検証、性能検証）、試験設計支援
– OSSコミュニティエスカレーション、等

• セミナ、トレーニングの提供
– 「PostgreSQLパフォーマンスチューニング入門」（7/27）
– 「LifeKeeper for Linuxで構築・運用する高可用PostgreSQLシステム」

• 学習用コンテンツのオンライン販売
– PostgreSQLアーキテクチャ入門（自習用教材）
– OSDL DBT-3によるPostgreSQLの性能評価～SATA HDD＆SATA SSD編（技術検
証レポート）

詳細は http://www.uptime.jp をご覧ください。


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


PostgreSQLバックアップの基本

More Related Content

What's hot (20)

Similar to PostgreSQLバックアップの基本 (20)

More from Uptime Technologies LLC (JP) (9)

Recently uploaded (9)

PostgreSQLバックアップの基本