| データベースの基礎知識 | ||||
|---|---|---|---|---|
| データベース設計 | ||||
|---|---|---|---|---|
バックアップの種類
バックアップには、次の 3 つの方法があります。
- ホットバックアップ/コールドバックアップ
- 物理バックアップ/論理バックアップ
- フルバックアップ/差分バックアップ/増分バックアップ
ホット/コールドバックアップ
RDBMS でホット/コールドバックアップする方法は、以下のとおりです。
| MySQL | PostgreSQL | |
|---|---|---|
| ホットバックアップ | mysqldump | pg_dump |
| コールドバックアップ | OS の cp, scp, rsync コマンド | OS の cp, scp, rsync コマンド |
物理/論理バックアップ
「物理バックアップ」と「論理バックアップ」の性質の違いは、以下のとおりです。
| 性質 | 物理バックアップ | 論理バックアップ |
|---|---|---|
| フォーマット | バイナリ形式 | テキスト形式 |
| バックアップ速度 | 速い | 遅い バイナリ⇔テキストの変換が必要 |
| バックアップサイズ | 小さい | 大きい |
| データ書き換え | 困難 | 容易 (SQL 文を書き換えるだけ) |
| 移植性 | 低い 他のバージョン/RDBMS は不可 | 高い 他のバージョン/RDBMS でも可 |
| 用途 | 大規模リカバリ | 小規模リカバリ 別のマシンへ移植 |
RDBMS で物理/論理バックアップを取得する方法は、以下のとおりです。
| MySQL | PostgreSQL | |
|---|---|---|
| 物理バックアップ | MySQLEnterpriseBackup OS の cp, scp, rsync コマンド | pg_basebackup OS の cp, scp, rsync コマンド |
| 論理バックアップ | mysqldump mysqlpump | pg_dump |
フル/差分/増分バックアップ
「フルバックアップ」と「差分/増分バックアップ」の性質の違いは以下のとおりです。
| 性質 | フルバックアップ | 差分バックアップ | 増分バックアップ |
|---|---|---|---|
| リカバリ方法 | 単純 フルバックアップだけ | 複雑 フルと最後の差分 | 最も複雑 フルと全ての増分 |
| リカバリ時間 | 早い | 遅い | 最も遅い |
| バックアップ時間 | 長い | 短い (変更したデータだけ) | 最も短い |
| バックアップサイズ | 大きい | 小さい (変更したデータだけ) | 最も小さい |
RDBMS でフル/差分/増分バックアップを取得する方法は、以下のとおりです。
| MySQL | PostgreSQL | |
|---|---|---|
| フルバックアップ | mysqldump | pg_dump |
| 差分/増分バックアップ | バイナリログ (後述) MySQL Enterprise Backup | WAL ログ |
MySQL でバックアップの方法
実際に mysqldump を利用してホット/論理/フルバックアップを取得してみます。
mysqldump でバックアップ
mysqldump をリストア (復元)
mysql を利用して、mysqldump で取得したバックアップをリストアしてみます。
mysql -u ユーザー名 -p データベース名 < バックアップファイル名
+------+ | id | +------+ | 1 | | 2 | | 3 | +------+
+------+ | id | +------+ | 1 | | 2 | | 3 | +------+
ポイントインタイムリカバリ (PITR)
適用するログにより、データを任意の時点に戻すことができます。
バックアップはデータベースに負荷をかけるため、高頻度で取得できませんが、ログは高頻度 (COMMIT する度) に取得できます。(つまり、バックアップより直近のデータまで復元できます)
※ログ = バイナリログ (MySQL)、WAL ログ (PostgreSQL)、Redo ログ (Oracle)
バイナリログの具体例は以下のとおりです。(binlog_format = ROW)
CREATE TABLE log (time date, request varchar(20)); BEGIN; INSERT INTO log VALUES ( ‘2024/01/01’,‘GET /index’);
なお、Redo ログとの違いは以下で、物理的なページの内容に依存せずにデータを復元できます。
| Redo ログ | バイナリログ | |
|---|---|---|
| ログ形式 | 物理ログ MLOG_REC_UPDATE_IN_PLACE, space:1, page_no:4... | 論理ログ UPDATE log SET id=100... |
| ログ出力 | InnoDB ストレージエンジン層 | MySQL サーバー層 |
| 利用用途 | クラッシュリカバリ | ポイントインタイムリカバリ レプリケーション |
バイナリログの管理
*************************** 1. row ***************************
File: binlog.000003
Position: 2212
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 12345678-1234-5678-9abc-123456789abc:1+---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000001 | 501 | No | | binlog.000002 | 180 | No | | binlog.000003 | 2212 | No | +---------------+-----------+-----------+
+---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000001 | 501 | No | | binlog.000002 | 180 | No | | binlog.000003 | 2212 | No | | binlog.000004 | 197 | No | +---------------+-----------+-----------+
+---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000001 | 157 | No | +---------------+-----------+-----------+
MySQL でポイントインタイムリカバリ (PITR)
MySQL の mysqlbinlog を使って、実際にポイントインタイムリカバリを実施してみます。
事前準備
+------+ | id | +------+ | 1 | | 2 | | 3 | +------+
+------+
| id |
+------+
| 0 |
| 1 |
| 2 |
+------+
リストアを PITR に含めないように、バイナリログを分けておきます。
(ログを分けずに、１つのログで時間を指定して PITR もできます。)
+---------------+-----------+-----------+ | Log_name | File_size | Encrypted | +---------------+-----------+-----------+ | binlog.000001 | 478 | No | | binlog.000002 | 157 | No | +---------------+-----------+-----------+
id = 0 を INSERT した時点のバイナリログ (binlog.000001) をフラッシュし、新しいバイナリログ (binlog.000002) を作成しました。
ポイントインタイムリカバリ (PITR) を実施
以下の手順でポイントインタイムリカバリ (PITR) を実施します。
- バックアップをリストア
- mysqlbinlog でバイナリログを適用
バックアップをリストア
+------+ | id | +------+ | 1 | | 2 | | 3 | +------+
id = 0 を INSERT する前に復元できていることが確認できます。
mysqlbinlog でバイナリログを適用
ここから、先ほど FLUSH した INSERT 時のバイナリログ (binlog.000001) を適用します。
+------+
| id |
+------+
| 0 |
| 1 |
| 2 |
+------+バイナリログが適用できており、ポイントインタイムリカバリ (PITR) に成功しました。
最後に
関連記事
| データベースの基礎知識 | ||||
|---|---|---|---|---|
| データベース設計 | ||||
|---|---|---|---|---|
