PostgreSQLバックアップの基本

2. 自己紹介• 永安悟史（ながやすさとし）• 略歴 – 1997年よりネットベンチャーにてインターネットサービス開発・運用に従事。 – 2004年より（株）ＮＴＴデータにて、並列分散データベースの研究開発、技術支援・保守サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げなどに参画。 – 2009年、アップタイム・テクノロジーズを創業。• 専門分野 – データベースシステム、並列分散システム、クラスタシステム – オープンソース・インフラ技術 – ＩＴサービスマネジメント（ITIL）、ITインフラ運用管理（運用設計～運用）• 本業＠アップタイム・テクノロジーズ – オープンソース導入サポートサービスの提供 – セミナ、トレーニングの提供 – 学習用コンテンツのオンライン販売 – その他、OSSおよびDB系技術コンサルティング Copyright 2012 Uptime Technologies LLC, All rights reserved. 2

5. 実行中のプロセス$ ps -aef | grep postgrespostgres 22169 1 0 23:37 ? 00:00:00 /usr/pgsql-9.0/bin/postmaster -p 5432 -D /var/lib/pgsql/9.0/datapostgres 22179 22169 0 23:37 ? 00:00:00 postgres: logger processpostgres 22182 22169 0 23:37 ? 00:00:00 postgres: writer processpostgres 22183 22169 0 23:37 ? 00:00:00 postgres: wal writer processpostgres 22184 22169 0 23:37 ? 00:00:00 postgres: autovacuum launcher processpostgres 22185 22169 0 23:37 ? 00:00:00 postgres: archiver process archiving 00000001000000D60000004Epostgres 22187 22169 0 23:37 ? 00:00:00 postgres: stats collector processpostgres 23436 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE waitingpostgres 23437 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE waitingpostgres 23438 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] COMMITpostgres 24283 22169 5 23:45 ? 00:00:02 postgres: postgres postgres [local] idlepostgres 24301 22169 0 23:45 ? 00:00:00 postgres: postgres postgres [local] idlepostgres 24581 22169 0 23:45 ? 00:00:00 postgres: autovacuum worker process pgbenchpostgres 24527 22185 0 23:45 ? 00:00:00 cp pg_xlog/00000001000000D60000004E /var/lib/pgsql/9.0/backups/archlog/00000001000000D60000004E$ Copyright 2012 Uptime Technologies LLC, All rights reserved. 5

6. 実行中のデータベースクラスタ（ディレクトリ）# ls -ltotal 116drwx------ 10 postgres postgres 4096 Dec 14 19:00 basedrwx------ 2 postgres postgres 4096 Jan 10 00:28 globaldrwx------ 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.confdrwx------ 2 postgres postgres 4096 Jan 10 00:00 pg_logdrwx------ 4 postgres postgres 4096 Dec 4 13:47 pg_multixactdrwx------ 2 postgres postgres 4096 Jan 8 10:14 pg_notifydrwx------ 2 postgres postgres 4096 Jan 10 15:43 pg_stat_tmpdrwx------ 2 postgres postgres 4096 Dec 28 14:41 pg_subtransdrwx------ 2 postgres postgres 4096 Dec 4 14:47 pg_tblspcdrwx------ 2 postgres postgres 4096 Dec 4 13:47 pg_twophase-rw------- 1 postgres postgres 4 Dec 4 13:47 PG_VERSIONdrwxr-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# Copyright 2012 Uptime Technologies LLC, All rights reserved. 6

7. 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バッファ）（ブロック情報）（空き領域情報）制御情報ファイル群テーブルインデックストランザクションアーカイブ設定ファイルファイルファイルログファイルログファイル Copyright 2012 Uptime Technologies LLC, All rights reserved. 7

8. PostgreSQLの基本的なアーキテクチャ共有バッファを中心として、複数のプロセス間で連携しながら処理を行うマルチプロセス構造。 postgres （リスナプロセス）（ shared_buffers postgres 共 postgres 有（サーバプロセス）バ postgres （サーバプロセス）クライアントッ（サーバプロセス）ファ） writer （バックグラウンドライタ） wal writer （WALライタ）テーブルファイルトランザクションインデックスログファイルファイル Copyright 2012 Uptime Technologies LLC, All rights reserved. 8

9. メモリ（共有バッファ） • ディスク上のブロックをキャッシュするメモリ領域 – ディスク上のブロックのうち、アクセスするものだけを読み込む – ディスク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

10. データファイルの配置データベースクラスタ（PGDATA）領域システムカタログ（global）設定ファイルテーブルファイルテーブルファイル (postgresql.conf, pg_hba.conf) テーブルファイルインデックスファイルインデックスファイルその他制御ファイル等インデックスファイルデフォルトテーブルスペース（base）トランザクションログ（pg_xlog）ユーザデータベース（OID）ユーザデータベース（OID）ユーザデータベース（OID）テーブルファイルテーブルファイルテーブルファイルインデックスファイルインデックスファイルインデックスファイル外部テーブルスペース外部テーブルスペースアーカイブログ領域テーブルスペース領域 54.1. データベースファイルのレイアウト http://www.postgresql.jp/document/9.0/html/storage-file-layout.html Copyright 2012 Uptime Technologies LLC, All rights reserved. 10

12. バックアップとレストア／リカバリ• バックアップの難しさ – データはファイルの中にだけあるのではない – 通常は、共有バッファの内容が最新 – ファイルだけバックアップを取ってもダメ – ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で• バックアップの種類 – コールドバックアップ – ホットバックアップ – PITR（アーカイブログ）バックアップ• バックアップ＆レストア／リカバリはリハーサルをしよう！ – 簡単な試験や手順書を作るだけで満足してはいけない・・・ – そのバックアップセットで本当にリカバリできますか？ Copyright 2012 Uptime Technologies LLC, All rights reserved. 12

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

14. ホットバックアップ（pg_dump/pg_restore）• あるタイミングでデータの一貫性を保ちつつバックアップ（export） – シンプルかつ柔軟（テーブル単位のバックアップも可） – バックアップ時にサービス停止は起こらない。 – リカバリの際には、バックアップ時のデータに戻る。• 向いているケース – 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。 – データベース単位、テーブル単位でバックアップを取りたい場合。 – 論理バックアップが必要な場合（メジャーバージョンアップなど）• 向いていないケース – 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。 Crash WAL1 WAL2 WAL3 ①pg_dumpで ②障害発生スナップショットをバックアップ ③レストア Index Table Copyright 2012 Uptime Technologies LLC, All rights reserved. 14

16. 用語• オンラインWALファイル – pg_xlogディレクトリに配置されている（まだアーカイブされていない）WALファイル• アーカイブWALファイル（アーカイブログ） – アーカイブされたWALファイル• 完全リカバリ – （オンラインWALファイルを用いて）最新の状態まで戻すことのできるリカバリ• 不完全リカバリ – オンラインWALファイルを消失したため、最新の状態ではなく、アーカイブWALファイルまでしか戻せないリカバリ• ベースバックアップ（非一貫性バックアップ） – 共有バッファなどの状態に関係なく、ファイルシステムレベルで取得するファイルバックアップ。 – 「データベースのファイル」として一貫性の取れた内容である保証は無い。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 16

17. アーカイブWALとPITRを用いたバックアップ• ベースバックアップ（基準点）＋アーカイブWALファイル（更新差分） – サービスを継続したままベースバックアップを取得可能（非一貫性バックアップ） – クラッシュ直前の状態に復旧することが可能（完全リカバリの場合）• 向いているケース – データベースクラスタ全体の完全なバックアップを取りたい場合。 – クラッシュ直前の更新まで復旧させる必要がある場合。• 向いていないケース – データベース単位、テーブル単位などでバックアップを取得したい場合。 Crash WAL1 WAL2 WAL3 WAL4 ①ベースバックアップの取得（非一貫性 ②WAL1を ③WAL2を ④WAL3をバックアップ）アーカイブアーカイブアーカイブ Index WAL1 WAL2 WAL3 Table レストア＆リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 17

18. アーカイブWALとPITRを用いたリカバリ• ベースバックアップ（基準点）＋アーカイブWALファイル（更新差分） – ベースバックアップをレストア後、アーカイブWALファイルを使ってロールフォワードリカバリする。 – オンラインWALファイルが残っていれば、完全リカバリが可能。 – 前回のベースバックアップ以降、長期間が経過しているとアーカイブWALファイルが多くなり、ロールフォワードリカバリの時間が長くなる。 – 所要時間は、「ベースバックアップレストア時間＋アーカイブWALファイル適用時間」 ⑥リカバリ完了 WAL1 WAL2 WAL3 WAL4 ①ベース ⑤オンラインWAL バックアップを ②WAL1を ③WAL2を ④WAL3を（WAL4）を適用レストア適用適用適用 Index WAL1 WAL2 WAL3 Table レストア＆リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 18

19. 障害とリカバリのシナリオ• データベースクラスタ（テーブルスペース）領域のロスト、障害 – ベースバックアップからデータベースクラスタをレストアし、アーカイブログを用いてリカバリをする必要がある。 – オンラインWALファイルが残っている場合には「完全リカバリ」が可能。• オンラインWAL領域のロスト、障害 – PITRによるリカバリは「不完全リカバリ」となる。完全リカバリは不可。 – PostgreSQLが起動しなくなる可能性が高いため、ベースバックアップ＋アーカイブWALからリカバリを実施（不完全リカバリ）。• アーカイブWAL領域のロスト、障害 – アーカイブWAL領域の障害は、サービスにはすぐには影響しない。 – 但し、アーカイブが失敗し始めると、オンラインWAL領域を圧迫し始める。そのため、アーカイブを再開できるよう、アーカイブWAL領域を復旧させる必要がある。 – また、障害が発生した際には、ベースバックアップ以降のすべてのアーカイブ WALファイルがないとリカバリできないため、再度、ベースバックアップを取得する必要がある。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 19

20. リストア、リカバリ手順• PostgreSQLサーバを停止する• 障害の発生したデータベースを保存する（可能であれば） – データベースクラスタ – テーブルスペース – オンラインWALファイル（残っている場合は必ず退避しておく）• ベースバックアップをレストアする• ベースバックアップ以降のアーカイブWALファイルを、アーカイブWAL領域にレストアする• 退避しておいたオンラインWALファイルを配置する• リカバリ設定ファイル（recovery.conf）を作成する• PostgreSQLサーバを起動する（リカバリ処理は自動実行される） Copyright 2012 Uptime Technologies LLC, All rights reserved. 20

21. リストア、リカバリ概念図• ベースバックアップ、アーカイブWALファイル、オンライン WALファイルを用いてリカバリを行う。通常稼働時リカバリ時 ②アーカイブWALでリカバリ ②③ ログ適用 ③オンラインWAL でリカバリ Table WAL WAL Table WAL WAL Index Index アーカイブWAL アーカイブWAL 障害発生リカバリ対象データベース ①データをデータベースレストア Table Table Index Index ベースバックアップベースバックアップ Copyright 2012 Uptime Technologies LLC, All rights reserved. 21

22. 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[2011-12-12 06:32:53 JST] 31582: LOG: restored log file "000000010000000000000006" from archive(...snip...)[2011-12-12 06:33:40 JST] 31582: LOG: restored log file "00000001000000000000000F" from archive[2011-12-12 06:33:47 JST] 31582: LOG: restored log file "000000020000000000000010" 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 Copyright 2012 Uptime Technologies LLC, All rights reserved. 22

24. バックアップ、リカバリの運用• 指定したサイクルで定期的にベースバックアップを取得 – ベースバックアップスクリプトをcron等で実行し、ベースバックアップを取得 – 世代ごとにサブディレクトリが作られてベースバックアップを保存 – 指定した世代数を超えたベースバックアップは削除 – もっとも古い世代のベースバックアップ以前のアーカイブログを削除• 障害が発生した場合は、ベースバックアップおよびアーカイブWALからリカバリ – オンラインWALバックアップスクリプトを実行し、オンラインWALファイルを退避する – リカバリスクリプトを実行し、最新のベースバックアップ、およびオンライン WALファイルをレストアし、リカバリ設定ファイルを作成する – PostgreSQLサービスを起動し、リカバリを実行する Copyright 2012 Uptime Technologies LLC, All rights reserved. 24

25. ベースバックアップの世代管理• 指定したバックアップ世代数に合わせて、ベースバックアップとアーカイブログを管理する – 最新のベースバックアップを取得できたら、もっとも古いベースバックアップを削除する – アーカイブログは、もっとも古いベースバックアップ以前のものを削除する（例）ベースバックアップを3世代分保持する場合コピーデータベーススナップショットクラスタ（一時領域）アーカイブ、圧縮第0世代 WAL Rotate 第1世代 Rotate アーカイビング第2世代第0世代を取得後に削除第3世代第2世代以降に生成されたアーカイブログアーカイブログを保持バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 25

26. リカバリ時の動作• オンラインWALファイルを保存、最新の世代のベースバックアップからレストアし、リカバリ実施に必要な設定ファイルを作成する – データベースクラスタに残っているオンラインWALファイルを保存する（①） – ベースバックアップからレストアする（②） – オンラインWALファイルを再度配置する（③） – リカバリを開始したら、アーカイブWALファイルを適用していく（④）データベーススナップショット ②レストア（一時領域）クラスタ第0世代 WAL ①オンライン第1世代 WAL保存第2世代 ④適用 ③オンライン最新WAL WAL配置第2世代以降に生成されたアーカイブログアーカイブWALを保持バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 26

27. アーカイブWALファイルの消し込み• ベースバックアップを取得すると、そのベースバックアップより前のアーカイブWALファイルは不要になる – 具体的には ”START WAL LOCATION” より前のWALファイル – ベースバックアップ②を取得したら、アーカイブWAL①は不要 – 但し、世代管理は必要アーカイブWAL① アーカイブWAL② WAL WAL WAL WAL WAL WAL WAL WAL ベースベースバックアップ① バックアップ②• 消し込みの方法 – pg_archivecleanupコマンドを使う（contribモジュール） – tmpwatchでタイムスタンプで判断（24時間以上経過したら削除、等） Copyright 2012 Uptime Technologies LLC, All rights reserved. 27

29. 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/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 29

30. Barman• 2ndQuadrantの開発したPostgreSQLバックアップツール – バックアップの取得（複数サーバ、ネットワーク経由） – リストア／リカバリの実行 – バックアップセットの管理 – D2D （Disk to Disk）のツール – 複数サーバを対象としたバックアップ管理が可能 Barman - Backup and Recovery Manager for business critical PostgreSQL databases http://www.pgbarman.org/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 30

32. さらに詳しくなりたい方は• PostgreSQLアーキテクチャ入門（自習用教材） – 内容：プレゼンテーションを録画した動画、及び使用しているスライド – 動画時間：約55分 – スライドページ数：54ページ – ファイル形式：MP4（動画）およびPDF（スライド）• OSDL DBT-3によるPostgreSQLの性能評価（SATA HDD＆SATA SSD編） – 内容：技術検証レポート – ページ数：54ページ – ファイル形式：PDF いずれも http://www.uptime.jp から購入できます。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 32

33. PostgreSQLパフォーマンスチューニング入門• 日時：2012年9月14日（金） 14:30～17:30 （約3時間）• 場所：クロスコープ青山セミナールーム（東京メトロ外苑前駅）• 概要 – PostgreSQLを利用する際に必要となるパフォーマンス管理およびチューニングについて、その仕組みや手順などの基本的な知識を獲得することを目的とします。• 対象 – PostgreSQLを使っているアプリケーション開発者の方 – PostgreSQLをこれから使い始めるデータベース管理者の方 – 現在、他のRDBMSを使っており、今後のPostgreSQLの利用を検討している方 – PostgreSQLを使っているがパフォーマンス問題に困っている方• 前回の参加者の皆さまからのコメント（アンケートより） – 丁寧な内容で構築・運用時に押さえるべき点を把握できた – 各パラメータについてはある程度知っていたが体系的に学ぶことができた – ツールや分析方法に知らないことが多かった – 全体のアーキテクチャの説明により、チューニングの基本が納得できた• 詳細 – http://bit.ly/MgYKPB Copyright 2012 Uptime Technologies LLC, All rights reserved. 33

34. アップタイム・テクノロジーズについて• オープンソース導入サポートサービスの提供 – 各種OSS（ミドルウェア、ツールなど）についての調査・情報提供 – 設計（基盤～アプリ）、開発の支援 – 機能検証・性能見積もり支援（機能検証、性能検証）、試験設計支援 – OSSコミュニティエスカレーション、等• セミナ、トレーニングの提供 – 「PostgreSQLパフォーマンスチューニング入門」（7/27） – 「LifeKeeper for Linuxで構築・運用する高可用PostgreSQLシステム」• 学習用コンテンツのオンライン販売 – PostgreSQLアーキテクチャ入門（自習用教材） – OSDL DBT-3によるPostgreSQLの性能評価～SATA HDD＆SATA SSD編（技術検証レポート）詳細は http://www.uptime.jp をご覧ください。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 34

PostgreSQLバックアップの基本

Uptime Technologies LLC (JP)

Transcript

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

PostgreSQLバックアップの基本

Uptime Technologies LLC (JP)

Transcript