Patroni と PostgreSQL の高可用性etcd

パート 4: バックアップ、監視、およびチューニング

xdev.asia

目的_

このレッスンの後、次のことを行います:

• WAL アーカイブを設定する
• pg_basebackup を使用してバックアップを実行する
• 継続的な設定を行うアーカイブ
• データベースを特定の時点に復元_
• バックアップ戦略を自動化
• 災害復旧計画を実施

1。バックアップ戦略の概要

1.1。バックアップの種類_

A。論理バックアップ_

# pg_dump / pg_dumpall
pg_dump -h localhost -U postgres mydb > mydb.sql
pg_dumpall -h localhost -U postgres > cluster.sql

Pros:
✅ Easy to restore specific tables
✅ Portable across PostgreSQL versions
✅ Human-readable (text)
Cons:
❌ Slow for large databases
❌ Not suitable for PITR
❌ Requires downtime for consistent backup

B。物理バックアップ

# pg_basebackup / File system snapshot
pg_basebackup -D /backup/base -Ft -z -P

Pros:
✅ Fast backup and restore
✅ Enables PITR with WAL archiving
✅ Consistent snapshot
Cons:
❌ Cannot restore individual tables
❌ Must match PostgreSQL version
❌ Larger backup size

C。継続的アーカイブ (WAL アーカイブ)

WAL files archived continuously


Base backup
= Point-in-Time Recovery capability

Pros:
✅ Can restore to ANY point in time
✅ Minimal data loss (RPO: seconds)
✅ Online backup (no downtime)
Cons:
❌ More complex setup
❌ Requires storage for WAL archives
❌ More moving parts

1.2。 RTO と RPO: 目標) = どの程度のデータ損失が許容されますか?

Daily backup: Up to 24 hours data loss ❌
WAL archiving: Up to last archived segment (~16MB)
Synchronous replication: Zero data loss ✅

1.3。バックアップ戦略決定マトリックス

要件	解決策
データゼロ損失_	同期レプリケーション + PITR
高速リカバリ (<1 時間)	ストリーミングレプリケーション
PITR機能	WALアーカイブ + pg_basebackup
長期保持_	定期的な pg_basebackup
災害復旧	オフサイト バックアップ + PITR

2. WAL アーカイブ設定

2.1。 WAL アーカイブについて

WAL (先行書き込みログ) = トランザクション ログ ファイル

Normal operation:
  Transaction → WAL file → Data files
WAL archiving:
Transaction → WAL file → Data files
↓
Archive location (safe storage)

WALセグメント_:

# Default: 16MB per segment

Location: $PGDATA/pg_wal/
ls -lh /var/lib/postgresql/18/data/pg_wal/
000000010000000000000001  (16MB)
000000010000000000000002  (16MB)
000000010000000000000003  (16MB)
...

2.2。 WAL アーカイブの構成

PostgreSQL 構成

# Edit postgresql.conf or use ALTER SYSTEM
sudo -u postgres psql -c "
ALTER SYSTEM SET wal_level = 'replica';  -- or 'logical'
ALTER SYSTEM SET archive_mode = 'on';
ALTER SYSTEM SET archive_command = 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f';
ALTER SYSTEM SET archive_timeout = 300;  -- Force archive every 5 min
"

Restart PostgreSQL
sudo systemctl restart postgresql

パラメーターの説明:

wal_level: 'replica'

'minimal': No archiving possible
'replica': Required for archiving and replication
'logical': For logical replication
archive_mode: 'on'
Enable archiving
archive_command: 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
%f = WAL filename (e.g., 000000010000000000000001)
%p = WAL full path (e.g., /var/lib/postgresql/18/data/pg_wal/000000010000000000000001)
test ! -f = Don't overwrite existing files
cp = Copy to archive location
archive_timeout: 300
Force WAL switch every 5 minutes (even if not full)
Ensures RPO <= 5 minutes

アーカイブの作成ディレクトリ_

# On primary server
sudo mkdir -p /mnt/wal_archive
sudo chown postgres:postgres /mnt/wal_archive
sudo chmod 700 /mnt/wal_archive

Verify archiving working
sudo -u postgres psql -c "SELECT pg_switch_wal();"
Forces current WAL file to be archived
Check archive
ls -lh /mnt/wal_archive/
Should see WAL files appearing

2.3。高度なアーカイブ コマンド

A。リモート サーバー (rsync)

# archive_command using rsync
archive_command = 'rsync -a %p backup-server:/mnt/wal_archive/%f'

B にアーカイブします。 S3 (wal-g)

# Install wal-g
wget https://github.com/wal-g/wal-g/releases/download/v2.0.1/wal-g-pg-ubuntu-20.04-amd64.tar.gz
tar -xzf wal-g-pg-ubuntu-20.04-amd64.tar.gz
sudo mv wal-g-pg-ubuntu-20.04-amd64 /usr/local/bin/wal-g
sudo chmod +x /usr/local/bin/wal-g

Configure
sudo -u postgres tee /var/lib/postgresql/.walrc <<EOF
AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
AWS_REGION=us-east-1
WALG_S3_PREFIX=s3://my-bucket/postgres-wal
EOF
Set archive_command
archive_command = '/usr/local/bin/wal-g wal-push %p'

C にアーカイブします。圧縮してアーカイブ_

# Compress before archiving
archive_command = 'gzip < %p > /mnt/wal_archive/%f.gz'

Or with pigz (parallel gzip)
archive_command = 'pigz < %p > /mnt/wal_archive/%f.gz'

2.4。アーカイブ_

-- Check archiving status
SELECT archived_count,
failed_count,
last_archived_wal,
last_archived_time,
last_failed_wal,
last_failed_time
FROM pg_stat_archiver;

-- Example output:
--  archived_count | failed_count | last_archived_wal        | last_archived_time

-- ----------------+--------------+--------------------------+-----------------------------
--            1234 |            0 | 000000010000000000000056 | 2024-11-25 10:30:15.123456
-- If failed_count > 0, check logs!

# Check PostgreSQL logs for archive errors
sudo journalctl -u postgresql | grep -i archive

Common errors:
- Permission denied on archive directory
- Archive directory full
- Network timeout (for remote archiving)

3 を監視します。 pg_basebackup

3.1 を使用したベース バックアップ。基本的な pg_basebackup

# Full backup to directory
sudo -u postgres pg_basebackup 

-D /backup/base/$(date +%Y%m%d_%H%M%S) 

-Fp 

-Xs 

-P 

-v

Flags:
-D: Destination directory
-Fp: Plain format (directory)
-Xs: Stream WAL during backup (ensures consistency)
-P: Show progress
-v: Verbose

出力:

pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/6000000 on timeline 3
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_12345"
245678/245678 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/6000168
pg_basebackup: syncing data to disk ...
pg_basebackup: renaming backup_manifest.tmp to backup_manifest
pg_basebackup: base backup completed

3.2。圧縮 tar バックアップ

# Backup as compressed tar
sudo -u postgres pg_basebackup 

-D /backup/tar 

-Ft 

-z 

-P 

-v

Flags:
-Ft: Tar format
-z: Gzip compression
Result:
ls -lh /backup/tar/
base.tar.gz         (main data)
pg_wal.tar.gz       (WAL files)
backup_manifest     (verification)

3.3。リモート サーバーへのバックアップ

# Stream directly to remote server
sudo -u postgres pg_basebackup 

-D - 

-Ft 

-z 

| ssh backup-server "cat > /backup/postgres-$(date +%Y%m%d).tar.gz"

3.4。レプリケーションスロット_

# Create replication slot first
sudo -u postgres psql -c "
SELECT pg_create_physical_replication_slot('backup_slot');
"

Backup using slot
sudo -u postgres pg_basebackup 

-D /backup/base/$(date +%Y%m%d) 

-Fp 

-Xs 

-P 

-S backup_slot
Slot ensures WAL files aren't removed during backup

3.5を使用したバックアップ。バックアップ

# Check backup_manifest
cat /backup/base/20241125/backup_manifest | jq

Verify checksum
sudo -u postgres pg_verifybackup /backup/base/20241125
Output:
backup successfully verified
✅

4 を確認します。ポイントインタイムリカバリ (PITR)

4.1。 PITR の概念

PITR = データベースを任意の時点に復元 (バックアップだけではありません)時間)_

Timeline:

T0: Base backup taken
↓
T1: Transaction A committed
↓
T2: Transaction B committed
↓
T3: Transaction C committed (ERROR! Want to undo)
↓
T4: Now
With PITR, can restore to T2 (before Transaction C)

要件:_

1. ベース バックアップ (pg_basebackup)
2. バックアップからターゲットまでの WAL アーカイブ時間
3. 回復対象の指定

4.2。 PITR の準備

リカバリ ディレクトリの作成:

# Stop PostgreSQL on target server
sudo systemctl stop postgresql

Backup current data (safety)
sudo mv /var/lib/postgresql/18/data /var/lib/postgresql/18/data.old
Create new data directory
sudo mkdir -p /var/lib/postgresql/18/data
sudo chown postgres:postgres /var/lib/postgresql/18/data

ベースの復元バックアップ_:_

# From plain directory backup
sudo cp -a /backup/base/20241125/* /var/lib/postgresql/18/data/

Or from tar backup
cd /var/lib/postgresql/18/data
sudo -u postgres tar -xzf /backup/tar/base.tar.gz
sudo -u postgres tar -xzf /backup/tar/pg_wal.tar.gz

4.3。回復の構成

回復構成の作成:

# PostgreSQL 12+: Use recovery.signal + postgresql.conf

Step 1: Create recovery.signal
sudo -u postgres touch /var/lib/postgresql/18/data/recovery.signal
Step 2: Configure recovery in postgresql.conf
sudo -u postgres tee -a /var/lib/postgresql/18/data/postgresql.auto.conf <<EOF
restore_command = 'cp /mnt/wal_archive/%f %p'
recovery_target_time = '2024-11-25 10:30:00'
recovery_target_action = 'promote'
EOF

回復パラメータ_:_

restore_command: 'cp /mnt/wal_archive/%f %p'

How to fetch archived WAL files
%f = WAL filename
%p = Destination path
recovery_target_time: '2024-11-25 10:30:00'
Restore to this timestamp
recovery_target_action: 'promote'
After reaching target: promote to normal operation
Options: 'pause', 'promote', 'shutdown'

4.4.回復ターゲットのオプション_

A。特定の時間

-- In postgresql.auto.conf
recovery_target_time = '2024-11-25 10:30:00'

B に復元します。特定のトランザクション_

-- Find transaction ID
SELECT txid_current();  -- Before bad transaction

-- In postgresql.auto.conf
recovery_target_xid = '12345678'

C に回復します。特定の LSN

-- In postgresql.auto.conf
recovery_target_lsn = '0/6000000'

D に復元します。最新_

-- In postgresql.auto.conf

No recovery_target_* parameter
Will replay all available WAL

E に復元します。回復ターゲットの包含/排他

-- Default: exclusive (stop BEFORE target)
recovery_target_inclusive = 'off'

-- Inclusive: include target transaction
recovery_target_inclusive = 'on'

4.5。リカバリを実行_

# Start PostgreSQL
sudo systemctl start postgresql

Monitor logs
sudo journalctl -u postgresql -f

ログ出力:

2024-11-25 11:00:00 LOG: starting PostgreSQL 18.0
2024-11-25 11:00:01 LOG: entering standby mode
2024-11-25 11:00:02 LOG: redo starts at 0/6000000
2024-11-25 11:00:03 LOG: restored log file "000000010000000000000006" from archive
2024-11-25 11:00:05 LOG: restored log file "000000010000000000000007" from archive
2024-11-25 11:00:08 LOG: recovery stopping before commit of transaction 12345678, time 2024-11-25 10:30:00
2024-11-25 11:00:09 LOG: pausing at the end of recovery
2024-11-25 11:00:09 HINT: Execute pg_wal_replay_resume() to continue.

一時停止した場合、再開:

-- Check status
SELECT pg_is_in_recovery();
-- true

-- Resume (will promote if action = promote)
SELECT pg_wal_replay_resume();
-- Or promote manually
SELECT pg_promote();

回復を確認:

-- Check database state
SELECT pg_is_in_recovery();
-- false (if promoted)

-- Verify data
SELECT * FROM critical_table WHERE created_at >= '2024-11-25 10:25:00';
-- Should see data up to recovery target time

4.6。 PITR

After PITR, timeline increments:

Original timeline: 3
After PITR: 4
This prevents accidentally replaying WAL from "future" timeline

# Check new timeline
sudo -u postgres psql -c "
SELECT timeline_id FROM pg_control_checkpoint();
"

timeline_id
------------
4

5 後のタイムライン。 Patroni による自動化_

5.1。 Patroni WAL アーカイブ

patroni.yml で構成:

postgresql:
parameters:
wal_level: replica
archive_mode: 'on'
archive_command: 'test ! -f /mnt/wal_archive/%f && cp %p /mnt/wal_archive/%f'
archive_timeout: 300

Restore command for replicas
recovery_conf:
restore_command: 'cp /mnt/wal_archive/%f %p'

Patroni自動的に_:

• プライマリでアーカイブを構成_
• レプリカでリストアを構成
• タイムラインを処理します変更

5.2。バックアップ スクリプト

#!/bin/bash

backup.sh - Automated PostgreSQL backup
set -e
BACKUP_DIR="/backup/postgres"
RETENTION_DAYS=7
DATE=$(date +%Y%m%d_%H%M%S)
Create backup directory
mkdir -p "$BACKUP_DIR/$DATE"
Run pg_basebackup
sudo -u postgres pg_basebackup 

-D "$BACKUP_DIR/$DATE" 

-Fp 

-Xs 

-P 

-v 

-c fast
Verify backup
sudo -u postgres pg_verifybackup "$BACKUP_DIR/$DATE"
Create metadata
cat > "$BACKUP_DIR/$DATE/backup_info.txt" <<EOF
Backup Date: $(date)
Hostname: $(hostname)
PostgreSQL Version: $(sudo -u postgres psql -t -c "SELECT version();")
Database Size: $(du -sh "$BACKUP_DIR/$DATE" | awk '{print $1}')
EOF
Remove old backups
find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} ;
Log
echo "$(date): Backup completed successfully: $BACKUP_DIR/$DATE" | tee -a /var/log/postgres-backup.log
Optional: Upload to S3
aws s3 sync "$BACKUP_DIR/$DATE" "s3://my-bucket/postgres-backups/$DATE/"
Send notification
curl -X POST https://hooks.slack.com/... -d '{"text":"Backup completed"}'

cron によるスケジュール:

# Run daily at 2 AM
sudo crontab -u postgres -e

Add:
0 2 * * * /usr/local/bin/backup.sh >> /var/log/postgres-backup.log 2>&1

5.3。 WAL-G 統合

インストールWAL-G:

# Download
wget https://github.com/wal-g/wal-g/releases/download/v2.0.1/wal-g-pg-ubuntu-20.04-amd64.tar.gz
tar -xzf wal-g-pg-ubuntu-20.04-amd64.tar.gz
sudo mv wal-g-pg-ubuntu-20.04-amd64 /usr/local/bin/wal-g
sudo chmod +x /usr/local/bin/wal-g

構成:

# Create config
sudo -u postgres tee /var/lib/postgresql/.walrc <<EOF
AWS_ACCESS_KEY_ID=your_key
AWS_SECRET_ACCESS_KEY=your_secret
AWS_REGION=us-east-1
WALG_S3_PREFIX=s3://my-bucket/postgres
WALG_COMPRESSION_METHOD=lz4
WALG_DELTA_MAX_STEPS=6
EOF

Update postgresql.conf
archive_command = '/usr/local/bin/wal-g wal-push %p'
restore_command = '/usr/local/bin/wal-g wal-fetch %f %p'

元に戻すWAL-G:

# Full backup
sudo -u postgres wal-g backup-push /var/lib/postgresql/18/data

List backups
sudo -u postgres wal-g backup-list
name                          modified             wal_segment_backup_start
base_000000010000000000000004 2024-11-25T10:00:00Z 000000010000000000000004

WAL-G:

# Stop PostgreSQL
sudo systemctl stop postgresql

Clear data directory
sudo rm -rf /var/lib/postgresql/18/data/*
Restore latest backup
sudo -u postgres wal-g backup-fetch /var/lib/postgresql/18/data LATEST
Or restore specific backup
sudo -u postgres wal-g backup-fetch /var/lib/postgresql/18/data base_000000010000000000000004
Configure PITR (if needed)
sudo -u postgres touch /var/lib/postgresql/18/data/recovery.signal
echo "recovery_target_time = '2024-11-25 10:30:00'" | 

sudo -u postgres tee -a /var/lib/postgresql/18/data/postgresql.auto.conf
Start PostgreSQL
sudo systemctl start postgresql

6 で復元します。災害復旧計画_

6.1。 DR 戦略

3-2-1 ルール:

3: Keep 3 copies of data
2: Store on 2 different media types
1: Keep 1 copy off-site

Example:

Production database (live)
Local backup (same datacenter)
S3 backup (cloud, different region)

6.2。 DR チェックリスト_

準備:

✅ WAL archiving enabled and tested
✅ Regular base backups (daily/weekly)
✅ Off-site backup storage (S3, remote server)
✅ Backup verification automated
✅ Restore procedures documented
✅ DR drills scheduled (quarterly)
✅ Monitoring and alerting configured
✅ Backup retention policy defined
✅ Encryption for backups (at rest and in transit)
✅ Access controls (who can restore)

6.3。 DR シナリオと手順_

シナリオ 1: データベースの破損

# 1. Identify corruption
SELECT * FROM corrupt_table;  # ERROR

2. Stop PostgreSQL
sudo systemctl stop postgresql
3. Restore from last good backup
sudo rm -rf /var/lib/postgresql/18/data
sudo cp -a /backup/base/20241125 /var/lib/postgresql/18/data
4. Configure PITR to just before corruption
echo "recovery_target_time = '2024-11-25 09:55:00'" | 

sudo tee -a /var/lib/postgresql/18/data/postgresql.auto.conf
sudo touch /var/lib/postgresql/18/data/recovery.signal
5. Start and verify
sudo systemctl start postgresql

シナリオ 2: データセンターの障害

# 1. Provision new servers in different region

2. Install PostgreSQL + Patroni
3. Restore from off-site backup (S3)
aws s3 sync s3://my-bucket/postgres-backups/20241125 /backup/restore/
sudo cp -a /backup/restore /var/lib/postgresql/18/data
4. Restore WAL from S3
(configure restore_command with wal-g or S3)
5. Start cluster
sudo systemctl start patroni
6. Update DNS/Load balancer to new region
RTO: ~1-2 hours (depends on backup size and network)

シナリオ 3: 偶発的なデータ削除

# Oops: DELETE FROM users WHERE ...;  (without WHERE clause)

Option A: PITR to before deletion
(See section 4.4)
Option B: Restore to separate instance and copy data
sudo -u postgres pg_basebackup -D /tmp/restore ...
Start on different port
Copy missing data to production

6.4。回復指標

RTO (目標回復時間):

Target: < 2 hours for full DR

Breakdown:

Detection: 5-10 min
Decision: 10-15 min
Restore base backup: 30-60 min
Replay WAL: 10-30 min
Verification: 10-20 min
DNS/Traffic switch: 5-10 min

Total: ~70-145 min

RPO (回復ポイント)目的):

Target: < 5 minutes data loss

With synchronous replication: 0 (zero data loss)
With WAL archiving: < archive_timeout (e.g., 5 min)
With daily backup only: Up to 24 hours ❌

7。監視とアラート_

7.1。主要なバックアップ指標

-- Archive status
SELECT archived_count,
failed_count,
EXTRACT(EPOCH FROM (now() - last_archived_time)) AS seconds_since_last_archive
FROM pg_stat_archiver;

-- Alert if seconds_since_last_archive > 600 (10 min)

# Backup age
find /backup/base -maxdepth 1 -type d -name "202*" -mtime -1 | wc -l

Should be >= 1 (at least one backup in last 24h)

7.2。 Prometheus メトリクス_

# Alert rules
groups:


name: backup_alerts
rules:


alert: PostgreSQLArchivingFailed
expr: pg_stat_archiver_failed_count > 0
labels:
severity: critical
annotations:
summary: "WAL archiving failures detected"


alert: PostgreSQLNoRecentBackup
expr: time() - pg_backup_last_success_timestamp > 86400
for: 1h
labels:
severity: warning
annotations:
summary: "No backup in last 24 hours"


alert: PostgreSQLArchiveDelayHigh
expr: |
time() - pg_stat_archiver_last_archived_time > 600
for: 5m
labels:
severity: warning
annotations:
summary: "WAL archiving delayed > 10 min"

7.3。バックアップの検証_

#!/bin/bash





verify-backup.sh
BACKUP_DIR="/backup/base"
LATEST_BACKUP=$(ls -td $BACKUP_DIR/*/ | head -1)
echo "Verifying: $LATEST_BACKUP"
1. Check backup_manifest exists
if [ ! -f "$LATEST_BACKUP/backup_manifest" ]; then
echo "❌ backup_manifest missing"
exit 1
fi
2. Run pg_verifybackup
if sudo -u postgres pg_verifybackup "$LATEST_BACKUP" > /dev/null 2>&1; then
echo "✅ Backup verified successfully"
else
echo "❌ Backup verification failed"
exit 1
fi
3. Check size (should be reasonable)
SIZE=$(du -sb "$LATEST_BACKUP" | awk '{print $1}')
MIN_SIZE=1000000000  # 1GB minimum
if [ "$SIZE" -lt "$MIN_SIZE" ]; then
echo "⚠️  Backup size suspicious: $(du -sh "$LATEST_BACKUP" | awk '{print $1}')"
exit 1
fi
4. Test restore to temp location (optional, resource-intensive)
...
echo "✅ All backup checks passed"

8。ベスト プラクティス

✅ DO

1. WAL アーカイブを有効にする - PITR に必要
2. 自動化バックアップ - cron/systemd タイマーによる毎日の pg_basebackup_
3. 定期的なテスト復元 - 毎月の DR ドリル
4. 監視アーカイブ - 失敗時のアラート
5. 複数世代のバックアップを保持 - 毎日 7 回 + 毎週 4 回 + 毎月 12 回
6. オフサイトバックアップ - S3、異なるリージョン/データセンター
7. バックアップの暗号化 - 保存中および転送中_
8. HTMLTAG_387___文書化手順 -復元のためのランブック
9. バックアップの確認 - 各バックアップ後の pg_verifybackup
10. RTO/RPO の計算 -制限

❌禁止

1. テストをスキップしないでください - 未テストのバックアップ = バックアップなし
2. 禁止ローカルにのみ保存 - データセンターの障害 = データ損失_
3. アーカイブの失敗を無視しない - サイレントデータ損失のリスク
4. WAL も削除しないでください早期_ - PITR の必要性_
5. 保持を忘れないでください_ - ストレージ コストと回復の必要性
6. 同じディスクにバックアップしないでください - ディスク障害 = すべてが失われる_
7. 暗号化をスキップしないでください - セキュリティ/コンプライアンスのリスク_
8. そう想定しないでくださいworks - 検証、検証、検証

9。ラボ演習

ラボ 1: WAL アーカイブのセットアップ

タスク:

1. archive_mode と構成archive_command
2. アーカイブ ディレクトリの作成
3. WAL 切り替えを強制する: SELECT pg_switch_wal();
4. アーカイブ内の WAL ファイルを確認するディレクトリ_
5. pg_stat_archiver の監視

ラボ 2: 拠点を取得するバックアップ_

タスク:

1. pg_basebackupを使用してバックアップを作成
2. 検証pg_verifybackup
3. バックアップのサイズと時間の計算_
4. バックアップの圧縮とサイズの比較_
5. ドキュメントのバックアップメタデータ

ラボ 3: 実行PITR_

タスク:

1. タイムスタンプ付きのテストテーブルの作成_
2. 基本バックアップの作成
3. さらに挿入データ_
4. 特定のタイムスタンプに注意してください
5. タイムスタンプの後に「不良」データを挿入_
6. タイムスタンプ（不良データの前）に復元
7. リカバリポイントが正しいことを確認してください正解_

ラボ 4: バックアップの自動化

タスク:

1. 保持付きバックアップ スクリプトの作成_
2. 追加エラー処理と通知
3. cron によるスケジュール
4. テスト スクリプト実行
5. バックアップ ログの監視

ラボ 5: DRドリル_

タスク:

1. データベース全体の損失のシミュレーション (データ ディレクトリの削除)
2. バックアップからの復元
3. WAL の再生最新ポイントまで_
4. RTO (復元時間) を測定
5. データの整合性を検証
6. 学んだ教訓を文書化

10。トラブルシューティング

問題: アーカイブが機能しない

症状: failed_count > 0 print pg_stat_archiver_

Check:

# Check archive_command manually
sudo -u postgres bash -c 'f=000000010000000000000001; p=/var/lib/postgresql/18/data/pg_wal/$f; test ! -f /mnt/wal_archive/$f && cp $p /mnt/wal_archive/$f'

echo $?  # Should be 0

共通原因:

• アーカイブ ディレクトリに対するアクセス許可が拒否されました
• アーカイブ ディレクトリが存在しません
• ディスクがいっぱい
• ネットワークの問題 (リモート アーカイブの場合)

問題: pg_basebackup遅い

最適化:

# Use compression
pg_basebackup -z ...

Parallel copy (if multiple tablespaces)
pg_basebackup -j 4 ...
Adjust checkpoint_timeout
ALTER SYSTEM SET checkpoint_timeout = '15min';
Use faster storage for backup destination

問題: PITR が失敗します - WAL がありません見つかりました_

エラー: ファイル "000000010000000000000007" を開けませんでした: そのようなファイルはありません、またはディレクトリ_

原因: WAL ファイルがアーカイブまたは復元コマンドにありません間違っています_

修正:

# Check WAL exists in archive
ls -lh /mnt/wal_archive/000000010000000000000007

Test restore_command manually
sudo -u postgres cp /mnt/wal_archive/000000010000000000000007 /tmp/test_wal
If missing, cannot recover to that point
Restore to earlier point or use latest available WAL

11。概要_

バックアップ戦略の概要

___HTM LTAG_607___時間/日

方法	RPO___ HTMLTAG_594___	RTO	複雑さ	使用ケース_
pg_dump	時間	低	小規模 DB、移行
pg_basebackup	最後のバックアップ	30-120分	中	_定期バックアップ
WAL アーカイブ	分	30-120分_	中	PITR機能
レプリケーション	秒/0	_30-60秒	高_	HA、データ損失なし_

主要な概念

✅ WAL アーカイブ_ - トランザクションの継続的なバックアップログ

✅ pg_basebackup - クラスター全体の物理バックアップ

✅ PITR -ベース バックアップ + WAL

✅ RTO を使用して任意の時点に復元します。どのくらいの速さで復元できますか?回復

✅ RPO - データ損失の許容範囲

✅ 3-2-1 ルール - 3 コピー、2 メディア タイプ、1 オフサイト

回復チェックリスト

•  PostgreSQL の停止
•  ベースを復元backup
•  recovery.signal の作成
•  restore_command の構成
•  リカバリターゲットの設定 (time/xid/lsn)
•  PostgreSQL を開始
•  リカバリ ログを監視
•  リカバリ ポイントを確認_
•  満足した場合は昇格
•  場合はレプリケーションを更新必要

次のステップ_

レッスン 17 では、_モニタリングとオブザーバビリティ:

• Prometheus + Grafana について説明します。セットアップ
• 主要なPostgreSQLメトリクス_
• Patroni監視___HTMLTAG_717__HTMLTAG_718___ログ集計
• アラート戦略
• パフォーマンスダッシュボード_