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

35,885 views

Published on

2012年5月24日に開催された「第2回『いまさら聞けない!システム運用・管理のコツ』」のセッション「いまさら聞けないPostgreSQL運用管理」の講演資料です。

Published in: Technology
0 Comments
40 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
35,885
On SlideShare
0
From Embeds
0
Number of Embeds
7,651
Actions
Shares
0
Downloads
396
Comments
0
Likes
40
Embeds 0
No embeds

No notes for slide

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

  1. 1. いまさら聞けないPostgreSQL運用管理 アップタイム・テクノロジーズ 永安 悟史 2012.5.24 Copyright 2012 Uptime Technologies LLC, All rights reserved. 1
  2. 2. 自己紹介• 永安 悟史 (ながやす さとし)• 略歴 – 1997年よりインターネットベンチャーにてネットサービス開発・運用に従事。 – 2004年より(株)NTTデータにて、並列分散データベースの研究開発、技術支援・保守 サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げ、 サービス運用などに従事。 – 2009年、アップタイム・テクノロジーズを創業。• 専門分野 – データベースシステム、並列分散システム、クラスタシステム – オープンソース・インフラ技術 – ITサービスマネジメント(ITIL)、ITインフラ運用管理(運用設計~運用)• 本業@アップタイム・テクノロジーズ – オープンソース導入サポートサービス – データベース・コンサルティング – ITサービスマネジメント・コンサルティング Copyright 2012 Uptime Technologies LLC, All rights reserved. 2
  3. 3. DevsとOpsを経験してみて• 運用担当者こそ技術的知識を – データベースの運用管理は特に難しい – 非計画停止はもとより、データロストは致命的• プロジェクト管理や要件定義の甘さが運用に跳ねる – バッチ処理 – バックアップ・リカバリ(可用性)設計 – メンテナンス設計• 「運用でカバー」と言わせないために – 基盤設計時・運用設計時に「合理的なツッコミ」をできるか? – 適切なタイミングで適切なツッコミを入れられるスキルを Copyright 2012 Uptime Technologies LLC, All rights reserved. 3
  4. 4. いまさら聞けないPostgreSQL運用管理 アジェンダ(1)アーキテクチャ概要(2)初期設定(3)データベースの監視(4)パフォーマンス・チューニング(概論、SQL編、GUC編)(5)バックアップ・リカバリ(概論、PITR、運用) Copyright 2012 Uptime Technologies LLC, All rights reserved. 4
  5. 5. (1)アーキテクチャ概要Copyright 2012 Uptime Technologies LLC, All rights reserved. 5
  6. 6. 実行中のプロセス$ 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. 6
  7. 7. 実行中のデータベースクラスタ(ディレクトリ)# 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. 7
  8. 8. 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. 8
  9. 9. PostgreSQLの基本的なアーキテクチャ 共有バッファを中心として、複数のプロセス間で連携しながら処理を行うマルチプロセス構造。 postgres (リスナプロセス) ( shared_buffers postgres 共 postgres 有 (サーバプロセス) バ postgres (サーバプロセス)クライアント ッ (サーバプロセス) フ ァ ) writer (バックグラウンド ライタ) wal writer (WALライタ) テーブル ファイル トランザクション インデックス ログファイル ファイル Copyright 2012 Uptime Technologies LLC, All rights reserved. 9
  10. 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
  11. 11. (2)初期設定Copyright 2012 Uptime Technologies LLC, All rights reserved. 11
  12. 12. PostgreSQLの設定• カーネルパラメータ – 共有メモリ、セマフォの設定 – ハードウェアのスペックによっては、デフォルトのままではPostgreSQL起動 時にエラーとなる• postgresql.conf – PostgreSQLパラメータ設定ファイル – initdbコマンドでデータベースクラスタを作成すると生成される• pg_hba.conf – ホストベースアクセス認証(HBA)設定ファイル – 接続元のホスト情報(IP)を使ってアクセス制御を行う Copyright 2012 Uptime Technologies LLC, All rights reserved. 12
  13. 13. postgresql.confで設定できる項目• 共有バッファ• WALバッファ• ワークメモリ(ソートメモリ)• チェックポイント• バックグランドライタ• 自動VACUUM Copyright 2012 Uptime Technologies LLC, All rights reserved. 13
  14. 14. 共有バッファ、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 Copyright 2012 Uptime Technologies LLC, All rights reserved. 14
  15. 15. 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 Copyright 2012 Uptime Technologies LLC, All rights reserved. 15
  16. 16. 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 onlylocal 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 Copyright 2012 Uptime Technologies LLC, All rights reserved. 16
  17. 17. (3)データベースの監視Copyright 2012 Uptime Technologies LLC, All rights reserved. 17
  18. 18. なぜ「監視」が重要なのか?• PDCA(Plan-Do-Check-Action)を回すため – データベースがきちんとサービスを提供しているか? – 性能レベルが落ちていないか?• 監視は「Action」につなげるための「Check」 – チューニングを行う – ハードウェアの増強を行う – メンテナンスを行う• 「何のために、何を監視するのか」 – あらかじめ決めておくことが重要 Copyright 2012 Uptime Technologies LLC, All rights reserved. 18
  19. 19. OSパフォーマンス監視• vmstat• iostat• mpstat• sar• ps• free Copyright 2012 Uptime Technologies LLC, All rights reserved. 19
  20. 20. データベースの何を監視するのか?• SQLパフォーマンス監視 – セッション数 – キャッシュヒット率 – ディスクI/O• ディスク領域監視 – データ領域(テーブルスペース)、オブジェクトサイズ – トランザクションログ領域 – アーカイブログ領域• サーバログ監視 – FATALログ、ERRORログ、WARNINGログ、LOGログ• システムリソース監視 – CPU、メモリ、ネットワーク、ディスク、プロセス・・・ Copyright 2012 Uptime Technologies LLC, All rights reserved. 20
  21. 21. 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ビュー Copyright 2012 Uptime Technologies LLC, All rights reserved. 21
  22. 22. 監視結果の可視化 • サンプルWebアプリを数日間実行し、その間のトランザク ション数およびデータベースサイズを計測 データベースサイズとトランザクション数 740 1200 720 トランザクション数(TPM) 1000 700DBサイズ(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で計測 Copyright 2012 Uptime Technologies LLC, All rights reserved. 22
  23. 23. 全体の傾向を可視化する• pg_statinfo/pg_reporterを使って、アクセス統計情報を可視化する。 – データベース統計情報 – ディスク使用状況 – テーブル統計情報 – チェックポイント情報 – Autovacuum実行状況 – SQL文実行状況 – 等・・・pg_statsinfo: Project Home Pagehttp://pgstatsinfo.projects.postgresql.org/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 23
  24. 24. (4)パフォーマンスチューニング(概論) Copyright 2012 Uptime Technologies LLC, All rights reserved. 24
  25. 25. パフォーマンスは何で決まるか?• 「単一クエリのレスポンス×クエリの同時実行数」 – 単一クエリのレスポンス • サーバ・クライアント間通信(ネットワーク) • SQLの構文解析、最適化(CPU処理) • ロックの競合(ロック待ち、デッドロックの発生) • テーブル、インデックス、ログへのI/O量(ディスクI/O) • ソート、結合などの演算処理(CPU処理、ディスクI/O) – クエリの同時実行数 • 接続クライアント数(いわゆるWebユーザ数) • コネクションプール接続数• 全体としてハードウェアのキャパシティの範囲内であるか? – ネットワーク、ディスクI/O、メモリ、CPUなどがボトルネックとなり得る。 – ただし、ボトルネック自体は「結果」であり、「原因」ではない。 – 「なぜ、それがボトルネックになっているのか?」が重要。 • テーブル設計? SQL文? 同時接続数? HW? 設定パラメータ?・・・ Copyright 2012 Uptime Technologies LLC, All rights reserved. 25
  26. 26. データベースを構成するハードウェアリソース• 複雑な構造を持つRDBMSでは、ボトルネックはいたるところに発生し得 るため、まずはきちんと切り分けることが重要。 – いきなりパラメータチューニングとかを始めない。 CPUネック? ソート? スキャン? CPU ネットワーク インターフェース メモリ ロック待ち? ネットワーク? プロセス空間 プロセス空間 共有メモリ プロセス空間 スワップ発生? ディスクキャッシュ 読み込み? 書き込み? テーブル/インデックス? トランザクションログ? ディスクソート? ディスク データベースサーバ Copyright 2012 Uptime Technologies LLC, All rights reserved. 26
  27. 27. パフォーマンス問題の切り分け • データベースの構成要素ごとに分解していく ファイルシステム パーサボトルネック sys 実行負荷 オプティマイザ user CPU 実行回数 エグゼキュータ io wait I/O量 idle ディスク性能 メモリ スワップ ディスク性能 WAL WAL生成量 共有バッファ ディスク データ 読み データサイズ その他 bgwriter 書き デッドロック checkpoint 回数 ロック その他 書き出し量 その他 ネットワーク Copyright 2012 Uptime Technologies LLC, All rights reserved. 27
  28. 28. パフォーマンス改善の基本手順• 全体のパフォーマンスの傾向をつかむ – どのデータベース、テーブルへのアクセスか? HWの利用状況はどうか? – どのメトリックスとどのメトリックスが相関があるか?• 遅いSQL文を特定する or 実行回数の多いSQLを特定する – log_min_durationオプション – pgFouine• 特定のSQLだけが遅い場合・・・ – SQLのクエリプランおよび実行状況を確認する(EXPLAIN)• 遅いSQLが特定されない(偏りがない)場合・・・ – ハードウェアリソースのボトルネックを探す• 対策を実施する – SQL文を書き換える、インデックスを張る、テーブル設計を修正する – アプリケーションを修正する – ハードウェアを増強する – 他・・・ Copyright 2012 Uptime Technologies LLC, All rights reserved. 28
  29. 29. (4)パフォーマンスチューニング(SQL編) Copyright 2012 Uptime Technologies LLC, All rights reserved. 29
  30. 30. SQLパフォーマンス分析• pgFouineによる問題SQL文の抽出、ランキング作成 – 総実行時間=レスポンスタイム(実行時間)×実行回数 – 最長レスポンスタイム – 他・・・pgFouine - a PostgreSQL log analyzerhttp://pgfouine.projects.postgresql.org/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 30
  31. 31. SQLクエリ文字列の生成方法の問題• アプリケーションコードでSQL文を作成する際、指定する条 件に応じてFROM句やJOINを最適化する必要がある。• アプリ内で文字列を連結してSQL文を生成しても、必ずしも パフォーマンスのよいSQL文が作成されるとは限らない。• (例)使われていないテーブルのJOINとソート、等 Copyright 2012 Uptime Technologies LLC, All rights reserved. 31
  32. 32. SQLチューニング(例)• 無駄なJOINをなくす – 使っていないテーブル(特に詳細テーブルB)のJOINを排除し、最小 限のリソース(メモリ)で処理を行う。 – 詳細テーブルBだけでも500MB以上あるので、不用意にJOINしてい てはメモリがいくらあっても足りない(上限はwork_memで設定。上 限を超えるとディスクを使う)。• LIMITを使用して、ソート時のデータ量を抑制する – 可能な限り(集約系以外は基本的に)LIMITを使用する。 – サブクエリでLIMITをかける(最初のJOINをする前にデータ量を抑 制)。• インデックスを作成、インデックスが効くクエリに書き換える Copyright 2012 Uptime Technologies LLC, All rights reserved. 32
  33. 33. SQLチューニング結果(例)• 一部クエリについてはパフォーマンスが改善された。 (以下は、ディスクキャッシュが効いていない状況下で測定) SQLチューニング結果 40 35 30 実行時間(秒) 25 Before 20 Tuned 1 Tuned 2 15 10 5 0 Query 1 Query 2 Query 3• テーブル設計によってはパフォーマンス向上を実現できない場合もある。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 33
  34. 34. SQLチューニングチェックシート• 各テーブルのテーブル定義、インデックス定義、レコード件数は確認でき ていますか?• PostgreSQL のバージョンはいくつですか? postgresql.conf の内容は 確認できますか?• 重いSQL は特定できていますか?• 重いSQL はどのような実行プランになっていますか?• 大きなシーケンシャルスキャン、ソートはありませんか?• 想定していないスキャン、ソートが実行されている場合• インデックスが使われていない場合• インデックスが使われている場合• 「もうダメ!」と思ったときは(でも、できればそうなる前にw) 弊社「オープンソース導入サポートサービス」へご相談ください http://www.uptime.jp/go/oss Copyright 2012 Uptime Technologies LLC, All rights reserved. 34
  35. 35. SSDを導入してみると・・ Query Execution Time HDD SSD 16,000 14,000 12,000Elapsed 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/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 35
  36. 36. (4)パフォーマンスチューニング(GUC編) ※GUC(Grand Unified Configuration) PostgreSQLのパラメータ管理モジュール。postgresql.confで設定・管理する。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 36
  37. 37. パラメータチューニング(例)• 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設定値 ※PostgreSQL 8.1で計測 Copyright 2012 Uptime Technologies LLC, All rights reserved. 37
  38. 38. パラメータチューニング(例)• checkpoint_segments – shared_buffers=32000固定 checkpoint_segmentsと性能推移 500 450 400 350 pgbenchスコア(tps) 300 250 200 150 100 50 0 1 2 4 8 16 32 64 128 checkpoint_segments設定値 ※PostgreSQL 8.1で計測 Copyright 2012 Uptime Technologies LLC, All rights reserved. 38
  39. 39. パラメータチューニング(例)• shared_buffers – checkpoint_segments=32固定 共有バッファサイズとpgbenchスコア (checkpoint_segments=32) 500 450 400 350 pgbenchスコア(tps) 300 250 200 150 100 50 0 1000 2000 4000 8000 16000 32000 64000 shared_buffers設定値 ※PostgreSQL 8.1で計測 Copyright 2012 Uptime Technologies LLC, All rights reserved. 39
  40. 40. パラメータチューニング(例) • バックグラウンドライタ(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 時刻 時刻 ※PostgreSQL 8.1で計測 F.24. pg_buffercache http://www.postgresql.jp/document/9.0/html/pgbuffercache.html Copyright 2012 Uptime Technologies LLC, All rights reserved. 40
  41. 41. パラメータ設定におけるトレードオフ• 共有バッファを大きくすると・・・ – より多くのディスクブロックを共有バッファに保持できるため、パフォーマンス が向上する。 – 大量のdirtyページが発生するため、チェックポイント時の負荷が高くなる。• チェックポイントの間隔を大きくすると・・・ – チェックポイントの発生数を抑え、パフォーマンスが向上する。 – チェックポイント時の負荷が高くなる。 – クラッシュリカバリに要する時間が長くなる。• バックグラウンドライタを頻繁に動かす(多く書き出す)と・・・ – チェックポイントにおける負荷は減るが、書き出しのディスクI/Oが頻発する (書き出しの平準化により) 。 – 全体的なパフォーマンスが低下する。(特にディスクが1本の場合) Copyright 2012 Uptime Technologies LLC, All rights reserved. 41
  42. 42. (5)バックアップ・リカバリ(概論) Copyright 2012 Uptime Technologies LLC, All rights reserved. 42
  43. 43. バックアップとレストア/リカバリ• バックアップの難しさ – データはファイルの中にだけあるのではない – 通常は、共有バッファの内容が最新 – ファイルだけバックアップを取ってもダメ – ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で• バックアップの種類 – コールドバックアップ – ホットバックアップ – PITR(アーカイブログ)バックアップ• バックアップ&レストア/リカバリはリハーサルをしよう! – 簡単な試験や手順書を作るだけで満足してはいけない・・・ Copyright 2012 Uptime Technologies LLC, All rights reserved. 43
  44. 44. 興行収入5億ドルの “TOY STORY 2” は一度消えかけた http://www.tested.com/videos/44220-how-pixar-almost-lost-toy-story-2-to-a-bad-backup/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 44
  45. 45. コールドバックアップ• サーバプロセスをすべてシャットダウンしてデータファイル全体をバックアップ – バックアップの間、サービス停止が発生する。 – リカバリの際には、バックアップ時のデータに戻る。 – ファイルバックアップなのでレストアが簡単。• 向いているケース – 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。 – ストレージスナップショットが一般化した今、案外現実的。• 向いていないケース – サービスを停止させられない場合。 – 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。 Crash ①サービス WAL1 WAL2 WAL3 停止 & ②障害発生 ファイル バックアップ ③レストア Index Table Copyright 2012 Uptime Technologies LLC, All rights reserved. 45
  46. 46. ホットバックアップ(pg_dump/pg_restore)• あるタイミングでデータの一貫性を保ちつつバックアップ(export) – シンプルかつ柔軟(テーブル単位のバックアップも可) – バックアップ時にサービス停止は起こらない。 – リカバリの際には、バックアップ時のデータに戻る。• 向いているケース – 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。 – データベース単位、テーブル単位でバックアップを取りたい場合。 – 論理バックアップが必要な場合(メジャーバージョンアップなど)• 向いていないケース – 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。 Crash WAL1 WAL2 WAL3 ①pg_dumpで ②障害発生 スナップショットを バックアップ ③レストア Index Table Copyright 2012 Uptime Technologies LLC, All rights reserved. 46
  47. 47. (5)バックアップ・リカバリ(PITR) Copyright 2012 Uptime Technologies LLC, All rights reserved. 47
  48. 48. アーカイブログとPITRを用いたバックアップ• ベースバックアップ(基準点)+アーカイブログ(更新差分) – サービスを継続したままベースバックアップを取得可能(非一貫性バックアップ) – クラッシュ直前のWALの内容まで復旧することが可能• 向いているケース – データベースクラスタ全体の完全なバックアップを取りたい場合。 – クラッシュ直前の更新まで復旧させる必要がある場合。• 向いていないケース – データベース単位、テーブル単位などでバックアップを取得したい場合。 Crash WAL1 WAL2 WAL3 WAL4 ①ベースバック アップの取得 (非一貫性 ②WAL1を ③WAL2を ④WAL3を バックアップ) アーカイブ アーカイブ アーカイブ Index WAL1 WAL2 WAL3 Table レストア&リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 48
  49. 49. アーカイブログとPITRを用いたリカバリ• ベースバックアップ(基準点)+アーカイブログ(更新差分) – ベースバックアップをレストア後、アーカイブログをロールフォワードリカバリする。 – 前回のベースバックアップ以降、長期間が経過しているとアーカイブログが多くなり、リ カバリの時間が長くなる。 – ベースバックアップレストア時間+アーカイブログ適用時間×アーカイブログ数 ⑥リカバリ完了 WAL1 WAL2 WAL3 WAL4 ①ベース ⑤オンラインWAL バックアップを ②WAL1を ③WAL2を ④WAL3を (WAL4)を適用 レストア 適用 適用 適用 Index WAL1 WAL2 WAL3 Table レストア&リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 49
  50. 50. アーカイブログ関連パラメータ• 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 Copyright 2012 Uptime Technologies LLC, All rights reserved. 50
  51. 51. ベースバックアップの取得手順と取得対象• 前提条件 – アーカイブログの設定が有効になっていること• 取得手順 – pg_start_backup()でバックアップ開始 – データベースクラスタ全体のバックアップを取得 – pg_stop_backup()でバックアップ完了• 取得対象 – データベースクラスタ全体 – テーブルスペース(使用している場合) – XLOGファイル(pg_xlog以下)とpostmaster.pidファイルは除く Copyright 2012 Uptime Technologies LLC, All rights reserved. 51
  52. 52. リストア、リカバリ手順• PostgreSQLサーバを停止する• 障害の発生したデータベースを保存する(可能であれば) – データベースクラスタ – トランザクションログ(残っている場合は必ず保護する) – テーブルスペース• ベースバックアップをレストアする• ベースバックアップ取得以降のアーカイブログをレストアする• 最新のトランザクションログを配置する• リカバリ設定ファイル(recovery.conf)を作成する• PostgreSQLサーバを起動し、リカバリ処理を実行する Copyright 2012 Uptime Technologies LLC, All rights reserved. 52
  53. 53. 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. 53
  54. 54. (5)バックアップ・リカバリ(運用) Copyright 2012 Uptime Technologies LLC, All rights reserved. 54
  55. 55. バックアップ、リカバリの運用• 指定したサイクルで定期的にベースバックアップを取得 – ベースバックアップスクリプトをcron等で実行し、ベースバックアップを取得 – 世代ごとにサブディレクトリを作ってベースバックアップを保存 – 指定した世代数を超えたベースバックアップを削除 – もっとも古い世代のベースバックアップ以前のアーカイブログを削除• 障害が発生した場合は、ベースバックアップおよびアーカイブログからリ カバリ – XLOGバックアップスクリプトを実行し、オンラインWALファイルを保存 – リカバリスクリプトを実行し、最新のベースバックアップ、およびオンライン WALファイルをレストアし、リカバリ設定ファイルを作成 – PostgreSQLサービスを起動し、リカバリを実行 Copyright 2012 Uptime Technologies LLC, All rights reserved. 55
  56. 56. ベースバックアップの世代管理• 指定したバックアップ世代数に合わせて、ベースバックアップとアーカイブログを 管理する – 最新のベースバックアップを取得できたら、もっとも古いベースバックアップを削除 – アーカイブログは、もっとも古いベースバックアップ以前のものを削除 (例)ベースバックアップを3世代分保持する場合 コピー データベース スナップショット クラスタ (一時領域) アーカイブ、圧縮 第0世代 WAL Rotate 第1世代 Rotate アーカイビング 第2世代 第0世代を取得後に削除 第3世代 第2世代以降に生成された アーカイブログ アーカイブログを保持 バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 56
  57. 57. リカバリ時の動作• 最新のWALファイルを保存、最新の世代のベースバックアップからレストアし、リ カバリ実施に必要な設定ファイルを作成する – データベースクラスタに残っている最新のWALを保存(①) – ベースバックアップからレストア(②) – 最新WALを再度配置(③) – リカバリを開始したら、アーカイブログを適用(④) データベース スナップショット ②レストア (一時領域) クラスタ 第0世代 WAL 第1世代 ①最新WAL 保存 第2世代 ④適用 ③最新 最新WAL WAL配置 第2世代以降に生成された アーカイブログ アーカイブログを保持 バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 57
  58. 58. Q&ACopyright 2012 Uptime Technologies LLC, All rights reserved. 58
  59. 59. さらに詳しくなりたい方は• PostgreSQLアーキテクチャ入門(自習用教材) – 内容:プレゼンテーションを録画した動画、及び使用しているスライド – 動画時間:約55分 – スライドページ数:54ページ – ファイル形式:MP4(動画)およびPDF(スライド) – 価格:1,050円(税込)• OSDL DBT-3によるPostgreSQLの性能評価(SATA HDD&SATA SSD編) – 内容:技術検証レポート – ページ数:54ページ – ファイル形式:PDF – 価格:1,260円(税込) いずれも http://www.uptime.jp から購入できます。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 59
  60. 60. 【お問い合わせ先】アップタイム・テクノロジーズ合同会社永安 悟史E-mail: snaga@uptime.jpWeb: http://www.uptime.jp/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 60

×