データベースの停止が可能
・停止してデータファイルをコピー 24時間止められないシステム
・論理バックアップ
ある時点のSELECTした結果を保存 ・物理バックアップ
アーカイブ運用/バックアップモード必須
システム要件およびリカバリ要件
から、バックアップ手法を決定
→夜間のメンテ停止は可能？
→もしもの時、1日前まで
戻せれば良い？
障害復旧(バックアップ・リカバリ)
オンライン・バックアップからリカバリ
時間
データベース
表 データ
ベースの 状態
取得済み バック アップ
データベース
表 オンライン
バックアップ取得
データベース
表
データが更新されると WALファイル生成
アーカイブ運用中、
WALファイルを アーカイブとして 自動でコピー
UPDATE
データベース
表
WAL領域は循環利用され、
最新のWALファイルのみ 残っている
WALアーカイブは 明示的に削除するまで 保持される
データベース
表
障害発生
障害復旧(バックアップ・リカバリ)
オンライン・バックアップからリカバリ
時間
データベース
表 データ
ベースの 状態
取得済み バック アップ
データベース
表 バックアップを リストア
バックアップ以降のWAL アーカイブをすべてコピー
データベース
表
・・・
・・・
データベース破損の場合でもWAL領域が 正常であればカレントのWALファイルは 利用できる可能性が高い
バックアップ＋アーカイブ＋最新のWAL ファイルをすべて適用してリカバリ 実際には、recovery.confファイルに アーカイブファイルのコピーコマンドと、
どの時点までリカバリするかを指定する
・restore_commnad で、アーカイブ ファイルの位置を指定
・recovery_target_timeで、どの時点 まで復旧するか指定
(xid,timeline,recoverypoint)
【参考】バックアップ・リカバリの詳細
物理バックアップの参考情報
アーカイブ運用の設定- https://www.postgresql.jp/document/current/html/continuous-archiving.html#BACKUP-ARCHIVING-WAL
ベースバックアップの取得- https://www.postgresql.jp/document/current/html/continuous-archiving.html#BACKUP-BASE-BACKUP
リカバリ- https://www.postgresql.jp/document/current/html/continuous-archiving.html#BACKUP-PITR-RECOVERY
押さえておくべきキーワードPITR(Point In Time Recovery)、timeline、recovery.conf
論理バックアップの参考情報
pg_dump（all）/pg_restore全ての使い方をマスターしておくこと
pg_dump論理バックアップを独自形式で取得(テキスト形式も選択可能)
独自形式のバックアップは、pg_restoreを用いてリストア
pg_dumpall論理バックアップをテキスト形式で取得
アジェンダ
データベースに求められること
データベースに求められる 「高性能」 「同時実行性」 「耐障害性」
などの基本を整理し、これらを実現するRDBMSの重要なキーワード を解説
RDBMSの構造
前章で挙げたデータベースとしての基本が、PostgreSQLでは どのような仕組みで実装されているかを解説
DBA(データベース管理者)のタスク
RDBMSの構造から定期的なメンテナンスの必要性を解説し、管理者 が実施する具体的なタスクやその実施方法を解説
SQL開発
RDBMSの共通言語である 「SQL」 の基本を解説
本日は試験範囲を紹介する程度です。
DB構造をもとに、それぞれがどのように動作するか理解する
・メモリ
・プロセス
・ディスク
shared_buffers wal_buffers
work_mem
wal_writer
archive stats_collector
autovacuum postgres
backend
logger
database
maintenance_work_mem
client
WALファイル
WALアーカイブ
サーバログ
設定ファイル 管理ファイル
SQL実行時の挙動
処理は
トランザクション単位
再利用可能なデータを キャッシュ
WAL
ログ先行書き込み CHECKPOINT
テーブル インデックス等
writer
checkpoint
SQL実行時の挙動
セッション開始：postgresプロセスが認証を担当
①クライアントから認証要求
②postgresプロセスによる認証が完了すると、postgres backendプロセスが起動し、
クライアントとセッションを確立
※セッション毎にbackendプロセスが起動され、クライアントと1対1対応する
shared_buffers ｗal _buffers
work_mem
writer wal_writer
archive stats_collector autovacuum_
postgres
backend
logger
database
maintenance _work_mem
WALファイル
WALアーカイブ
サーバログ 設定ファイル 管理ファイル client
backend client
backend client
SQL実行時の挙動
参照：共有バッファを利用
①クライアントからクエリ発行
②backendプロセスが必要なデータを共有バッファから探す
③バッファ上に無い場合は、ディスクの該当ブロックをバッファに載せる
④backendプロセスがクライアントに結果を返却
※アクセスしたデータはバッファ上にキャッシュされ、以降は高速に結果を返す仕組み
shared_buffers ｗal _buffers
work_mem
writer wal_writer
archive stats_collector autovacuum
backend
logger
database
maintenance _work_mem
WALファイル
WALアーカイブ
サーバログ 設定ファイル 管理ファイル client
SQLの特徴
表名や列名を指定し、データへのアクセスを可能とする
すべてのRDBMS共通の言語
データの物理位置（メモリアドレスなど）を意識せずアクセスが可能テーブル名、列名を指定し、条件に合致する行を漏れなく抽出
データの物理構造やアクセス方法はRDBMSに任せる
テーブルの作成や稼働状態の確認などもSQLで実施 SQLの分類
分類 コマンド例 特徴