バックアップとリストア──転ばぬ先の杖
最終章は運用についてです。
運用でまず重要なのは、
そのあとの節では、
バックアップの種類
バックアップには次の種類があります。
- 論理バックアップ
- SQLをそのまま保存する。無停止かつお手軽に実施できる。バックアップした時点までしか戻せない
- 物理バックアップ
- サーバを止めてデータファイルをコピーする。多くの場合、
論理バックアップより高速に実施できる。バックアップした時点までしか戻せない - オンラインバックアップとPITR
(Point In Time Recovery) - 無停止でデータファイルとWALアーカイブをコピーする。最新状態までの任意の時点に戻せる。運用コストは高くなる
論理バックアップは一般的に、rsync
などでファイルバックアップすればよく、
バックアップした直後から最新状態までの任意の時点に戻すには、
このようにそれぞれ、
リストアの設計
リストアを設計するうえでのポイントは稼働率です。表1のように、
稼働率 | 年間停止時間 | バックアップとリストアの方針 |
---|---|---|
90% | 36. | 月に複数回のメンテナンス時間を設けることができる。論理バックアップや物理バックアップとリストアで十分に対応できる |
99% | 3. | オンプレミスなら予備のマシンが必要になる。大規模なデータの場合はリストアの所要時間の把握などが必要になる |
99. | 8. | 法定停電や24時間365日対応などシステム以外の部分にも影響が出る99. |
99. | 5分間 | レプリケーションを利用した、 |
99. | 32秒間 | 無停止で運用する専用サーバや、 |
稼働率を高くするにはオンラインで行えるバックアップは必須ですし、
自分たちの稼働率を決めて、
pg_dump──オンラインで論理バックアップ
一番スタンダートなのは論理バックアップツールであるpg_
- プレーンテキスト形式
(SQL) - カスタムアーカイブ形式
(圧縮したバイナリ) - ディレクトリ形式
(表単位で圧縮したバイナリ) - TAR形式
(表単位のバイナリ)
お勧めは、
カスタムアーカイブ形式でのバックアップとリストアは次のように実行します。
$ pg_dump -Fc データベース名 -U ユーザー名 \
-h ホスト名 -f /tmp/dump.custom
$ pg_restore -d データベース名 /tmp/dump.custom
このようにDBの停止を伴わずコマンド一つでバックアップし、
pg_basebackup──PITRのためのオンラインバックアップ
pg_
pg_postgresql.
を次のように変更してWALアーカイブモードを有効にしておく必要があります。
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /usr/local/pgsql/backup/%f
&& cp %p /usr/local/pgsql/backup/%f'
wal_
pg_
具体的なバックアップとリストアの方法は、
# service postgresql stop
$ pg_basebackup -D 出力先 -X s -P \
-h ホスト名 -U ユーザー名
$ pg_basebackup -D 出力先 -X s -P \
-h ホスト名 -U ユーザー名
$ rsync -av $PGDATA/pg_wal/ $BACKUP_WAL
$ rsync -av $PGDATA $BACKUP/old_pgdata
$ rm -rf $PGDATA
$ rsync -av $BACKUP/pgdata/* $PGDATA
rm -rf $PGDATA/pg_wal
$ rsync -av $BACKUP_WAL $PGDATA/pg_wal/
$ vi recovery.conf
restore_command = 'cp /usr/local/pgsql/backup/%f "%p"'
recovery_target_time = '2018/12/01 00:47:00'
# service postgresql start
リストア時には、
recovery.
で指定しているrestore_
このようにpg_
pg_rman──PITRを助けてくれるツール
「PITRをしたいけどリストア手順が多くて難しい……」
pg_
# pg_rman backup --backup-mode=full \
--compress-data --progress
# service postgresql stop
# pg_rman restore \
--recovery-target-time "2018/12/01 00:47:00"
# service postgresql start
バックアップをより詳しく知りたい方へ
チュートリアルの動画
レプリケーション──データベースのリアルタイム複製
PostgreSQLはバージョンアップのたびに進化しています。その中でもRDBMSの重要な機能であるレプリケーションは、
レプリケーションの役割
レプリケーションは、
昨今ではクラウドサービスを利用すると、
PostgreSQLではレプリケーションとして、
ストリーミングレプリケーション──堅牢な複製
PostgreSQLのレプリケーションとしての主流は、
ストリーミングレプリケーションは図1のとおり、
![図1 ストリーミングレプリケーションのしくみ 図1 ストリーミングレプリケーションのしくみ](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_001.png)
ストリーミングレプリケーションは、
ロジカルレプリケーション──自由度の高い複製
PostgreSQLのもう一つのレプリケーションが、
- PostgreSQLのメジャーバージョン違いでのレプリケーションが行える
- テーブル単位でのレプリケーション
- スタンバイへの書き込み
- スタンバイ側へのインデックスやトリガの設定
- 複数のプライマリから1つのスタンバイへ集約
自由度の高さを活かして、
手堅いストリーミングレプリケーションをメインに利用し、
レプリケーションを利用したスタンバイの構成
PostgreSQLでは図2のとおり、
![図1 レプリケーションを利用したスタンバイの構成 図1 レプリケーションを利用したスタンバイの構成](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_002.png)
カスケードレプリケーションは、
マルチレプリケーションは、
パーティション──テーブルの水平分割
レプリケーションと同じく、
本節では、
パーティションの役割
パーティションは、
![図3 パーティションのしくみ 図3 パーティションのしくみ](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_003.png)
たとえば月次で集計するユーザーの課金履歴があったとします。サービス開始当初は1つのテーブルでまったく問題がなかったとしても、
![図4 パーティションの活用例 図4 パーティションの活用例](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_004.png)
パーティションの使い方
続いて、
魅力いっぱいのPostgreSQLのパーティションを利用するためには、
親テーブルの作成 demo=# CREATE TABLE public."販売履歴" ( "商品名" character varying(64) NOT NULL, "価格" numeric NOT NULL DEFAULT 0, "売上日時" timestamp NOT NULL DEFAULT now(), "売上月" character varying(6) NOT NULL ) PARTITION BY LIST ("売上月"); 文字列指定の場合のパーティション demo=# CREATE TABLE "2018年10月" PARTITION OF "販売履歴" FOR VALUES IN ('201810'); demo=# CREATE TABLE "2018年9月" PARTITION OF "販売履歴" FOR VALUES IN ('20189'); demo=# CREATE TABLE "2018年8月" PARTITION OF "販売履歴" FOR VALUES IN ('20188'); demo=# CREATE TABLE "2018年7月" PARTITION OF "販売履歴" FOR VALUES IN ('20187'); demo=# CREATE TABLE "2018年6月" PARTITION OF "販売履歴" FOR VALUES IN ('20186'); データの投入 demo=# INSERT INTO "販売履歴" ("売上日時", "商品名", "価格", "売上月") VALUES ( '2018-10-21 21:12:00' , 'WEB+DB PRESS Vol.107', 1480, '201810' ); データの確認 demo=# SELECT "商品名","売上月" FROM "販売履歴"; 商品名 | 売上月 ----------------------+-------- WEB+DB PRESS Vol.107 | 201810 (1 row) demo=# SELECT "商品名","売上月" FROM "2018年10月"; 商品名 | 売上月 ----------------------+-------- WEB+DB PRESS Vol.107 | 201810 (1 row) demo=# SELECT "商品名","売上月" FROM "2018年9月"; 商品名 | 売上月 --------+-------- (0 rows) 範囲指定の場合のパーティション demo=# CREATE TABLE public."販売履歴2" ( "商品名" character varying(64) NOT NULL, "価格" numeric NOT NULL DEFAULT 0, "売上日時" timestamp NOT NULL DEFAULT now(), ) PARTITION BY RANGE ("売上日時"); demo=# CREATE TABLE "2018年10月RANGE" PARTITION OF "販売履歴2" FOR VALUES FROM ('2018-10-01 00:00:00') TO ('2018-11-1 00:00:00 '); demo=# INSERT INTO "販売履歴2" ("売上日時", "商品名", "価格") VALUES ( '2018-10-21 21:12:00','WEB+DB PRESS Vol.107',1480 ); 確認 demo=# SELECT * FROM "2018年10月RANGE"; 商品名 | 価格 | 売上日時 ----------------------+------+--------------------- WEB+DB PRESS Vol.107 | 1480 | 2018-10-21 21:12:00 (1 row)
ハッシュパーティション──バランス良く分割する
PostgreSQL 10で追加されたパーティションは、
![図6 ハッシュパーティションのしくみ 図6 ハッシュパーティションのしくみ](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_006.png)
これにより、
そのほかの改善点
PostgreSQL 11のパーティションは、
- パースツリーの作成などクエリを実行するための前準備処理中でもパーティションをすばやく削除できる
- クエリをエグゼキュータが実行中でもパーティションの削除を許可する
- パーティションのキーがUPDATE文で変更された行は、
更新された内容に基づいて、 自動的に対象のパーティションに移動させる - パーティション化されたテーブルに、
デフォルトのパーティションを指定する - パーティションテーブルからの外部キーを許可する・
パーティションテーブルに対してINSERT ON CONFLICT文を実行する - パーティションキーが一意性を保証する場合は、
パーティションテーブルの一意制約を許可する
毎年メジャーバージョンアップするPostgreSQLですが、
PostgreSQLのバージョンアップ
ここまで読んで、
メジャーバージョンアップとマイナーバージョンアップの違い
PostgreSQLのバージョンは、
- メジャーバージョンアップ
- 1年に1回、
機能追加や機能改善として行われる。第1章で詳述 - マイナーバージョンアップ
- 基本的には2月、
5月、 8月、 11月の3ヵ月に1回、 第二木曜日にバグ対応やセキュリティアップデートとして行われる。致命的な問題があれば例外として随時行われる
この周期でバージョンアップし、
マイナーバージョンアップはバグ対応やセキュリティアップデートですから、
メジャーバージョンアップには機能追加や変更も含まれます。場合によっては互換性のない仕様変更も含まれるため、
リリースノート
PostgreSQLの公式リリースノートはバージョンアップに有用です。変更点だけでなく、
マイナーバージョン──積極的に追随しよう
マイナーバージョンは、
マイナーバージョンアップはyum update
などで簡単に行えますが、
メジャーバージョンアップ──互換性がないこともある
PostgreSQLはMySQLとは異なり、
このように無停止で行うことが難しいメジャーバージョンアップですが、
以降では、
pg_dump──リストアしてバージョンアップ
一番簡単な方法は、
この方法は、
メリットは、
メンテナンス時間が取れ、
pg_upgrade──そのままバージョンアップ
メンテナンス時間は取れるがデータが大規模のため、
PostgreSQL 8.
ただし、
ロジカルレプリケーションによるローリングアップデート
PostgreSQL 10から11へのバージョンアップであれば、
![図7 ロジカルレプリケーションでのバージョンアップ 図7 ロジカルレプリケーションでのバージョンアップ](/assets/images/dev/feature/01/dex_postgresql/0004/thumb/TH800_007.png)
サービス都合でなかなかメジャーバージョンアップできなかったサービスも、
PostgreSQLの日本語情報源
PostgreSQLの魅力の一つは、
公式マニュアル
今回の記事でもたびたび紹介した日本語マニュアルは、
注意点として日本語マニュアルは、
日本語マニュアルは、
翻訳への参加
日本語マニュアルのGitHubのpublicリポジトリは、
GitHub上でのやりとりは日本語で行われており、
興味がある人は、
企業・団体によるレポート
個人で調べるには限界がありますが、
- SRA OSS, Inc. Japanの
「PostgreSQLに関する技術情報」 - Hewlett-Packard Enterprise Japan Co, Ltd. の
「PostgreSQL 11 新機能検証結果」 - PostgreSQL エンタープライズ・
コンソーシアムのワーキンググループ活動報告
postgresql-jpのSlack
PostgreSQLの有志が集まったSlackがあります。登録すれば誰でも参加できます。
PostgreSQLのコミッターのような上級者から、
特集のまとめ
本特集ではPostgreSQLについて紹介しました。
PostgreSQLに限らず、
その中でもPostgreSQLの魅力は、
最後になりましたが、
本誌最新号をチェック!
WEB+DB PRESS Vol.130
2022年8月24日発売
B5判/
定価1,628円
ISBN978-4-297-13000-8
- 特集1
イミュータブルデータモデルで始める
実践データモデリング
業務の複雑さをシンプルに表現! - 特集2
いまはじめるFlutter
iOS/Android両対応アプリを開発してみよう - 特集3
作って学ぶWeb3
ブロックチェーン、スマートコントラクト、 NFT