MySQLとPostgreSQLの基本的な論理バックアップと物理バックアップ

2. Backup Requirement
RTO（Recovery Time Objective）：目標復旧時間
–障害発生時に「どのくらいの時間で復旧させるか？」
RPO（Recovery Point Objective）：目標復旧時点
–障害発生時に「どの時点までのデータを復旧させる必要があるか？」
バックアップ計画を立てる為に、先ずは障害発生時のリカバリー要件を検討し方法を選択。

3. Backup Procedure
オフラインバックアップ
–物理バックアップ（コールドバックアップ)
–MySQL & PostgreSQLを停止してデータベースのバックアップを取得
オンラインバックアップ
–論理バックアップ
mysqldump, mysqlpump, pg_dump, pg_dumpallコマンドを使ってバックアップを取得（Lockやオプションは確認)
mysql, psql, pg_restoreコマンドによるリストア
※ 並列処理が可能：mysqlpump, pg_dump & pg_restore(共にPG9.6以降)
–物理バックアップ
pg_basebackup, pg_start_backup & pg_stop_backup + WALファイルをバックアップ（任意の時点にリカバリ可)
xtrabackup, mysqlbackup (差分バックアップ、任意の時点にリカバリ可)
※ MySQL, PostgreSQL共にレプリケーションを利用して物理的な障害などに対応可能。
※ pg_dumpはテキスト(psqlでリストア)、カスタム、tar、ディレクトリーでバックアップを取得。バイナリーはpg_restoreでリストア
バックアップ & リカバリー方法

4. Compared Version
MySQL PostgreSQL
root@localhost [mysql]> select @@version,now();
+-----------+---------------------+
| @@version | now() |
+-----------+---------------------+
| 8.0.18 | 2019-11-04 01:50:06 |
+-----------+---------------------+
1 row in set (0.00 sec)
postgres=# select version();
version
--------------------------------------
PostgreSQL 12.0 on x86_64-pc-linux-gnu,
compiled by gcc (GCC) 4.8.5 20150623
(Red Hat 4.8.5-39), 64-bit
(1 行)
PostgreSQL 12 Release date: 2019-10-03
https://www.postgresql.org/docs/12/release-12.html
MySQL 8.0.18 Release date: 2019-10-14
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html

5. Logical Backup (ALL)
MySQL PostgreSQL
# ❶ 全てのオブジェクトをバックアップ
-bash-4.2$ mysqldump --user=root --password=password --all-databases --
default-character-set=utf8mb4 --flush-logs --single-transaction --hex-blob
--triggers --routines --events --master-data=2 > all_dbs_20200105.sql
# ❶ dropデータベースを含まない
-bash-4.2$ pg_dumpall -f all_databases_20200105.sql
# ❷ dropデータベースを含む (リストア時はpostgresデータベースに接続)
-bash-4.2$ pg_dumpall --clean -f all_databases_with_drop_20200105.sql
-bash-4.2$ zcat ALLDB_20200104.sql.gz | head -n 40 | grep -v ^'--'
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `app` /*!40100 DEFAULT CHARACTER
SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N'
*/;
USE `app`;
DROP TABLE IF EXISTS `FTS_DOC`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
-bash-4.2$
https://dev.mysql.com/doc/refman/5.6/ja/mysqldump.html
https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
※ ここではInnoDBのトランザクションを利用出来る事を前提にバックアップ
※ MyISAM等トランザクション非対応のテーブルは,LOCKしてバックアップが必要
-bash-4.2$ cat all_databases_20200105.sql | grep -i create | head -n 10
CREATE ROLE application_role;
ALTER ROLE application_role WITH SUPERUSER INHERIT NOCREATEROLE NOCREATEDB
LOGIN NOREPLICATION NOBYPASSRLS PASSWORD 'md5eacb5421b43a0da9377231f';
CREATE ROLE postgres;
ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
REPLICATION BYPASSRLS PASSWORD 'md572f4e1133f9b86c968ef';
CREATE DATABASE app WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE
= 'ja_JP.UTF-8' LC_CTYPE = 'ja_JP.UTF-8';
CREATE TABLE public.btree (
CREATE TABLE public.const (
CREATE TABLE public.films (
-bash-4.2$
https://www.postgresql.jp/document/11/html/app-pg-dumpall.html
含 場合 適宜事前削除利用
等 指定

6. Logical Backup (Specific Schema)
MySQL PostgreSQL
# ❶ 特定スキーマをダンプ（カンマ区切りで複数指定可能)
-bash-4.2$ mysqldump --user=root --password=password --databases gis --
default-character-set=utf8mb4 --flush-logs --single-transaction --hex-blob
--triggers --routines --events --master-data=2 > dbs_20200105.sql
# ❶ dropデータベースを含まないPlainテキストフォーマットのダンプ
-bash-4.2$ pg_dump -Fp -f app.dump_plain app #Plainテキスト
# ❷ dropデータベースを含まないバイナリーフォーマットのダンプ
-bash-4.2$ pg_dump -Fc -f app.dump app #バイナリー
※ リストア時に-cオプションを指定してオブジェクトを削除可能
-bash-4.2$ pg_restore -c -d app app.dump
-bash-4.2$ cat dbs_20200105.sql | grep -ie create -ie drop
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `gis` /*!40100 DEFAULT CHARACTER
SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N'
*/;
DROP TABLE IF EXISTS `temp1`;
CREATE TABLE `temp1` (
DROP TABLE IF EXISTS `tokyo_area`;
CREATE TABLE `tokyo_area` (
-bash-4.2$
※ デフォルトでは INFORMATION_SCHEMAデータベースおよび performance_schema
データベースをダンプしません。必須では無いですが、これらをダンプするには、
コマンド行で明示的に指定し、--skip-lock-tables オプションも使用します。
--databases オプションでも指定可能。
-F format ( --format=format )
p : plain (平文のSQLスクリプトファイルを出力でpsqlでリストア)
c : custom (pg_restoreへの入力に適したアーカイブを出力)
d : directory (pg_restoreへの入力に適したアーカイブを出力)
t : tar (pg_restoreへの入力に適したアーカイブを出力)
※ Plainテキストバックアップの場合は、psqlでリストア可能
$ dropdb app
$ createdb -E UTF8 -l ja_JP.UTF-8 -T template0 -O application_role app
$ psql app < app.dump_plain
https://www.postgresql.jp/document/11/html/app-pgdump.html
https://www.postgresql.jp/document/11/html/app-pgrestore.html
https://www.postgresql.jp/document/11/html/app-dropdb.html
https://www.postgresql.jp/document/11/html/app-createdb.html
指定
複数 指定 事 可能
時 選択可能

7. Logical Dump Restore (ALL)
MySQL PostgreSQL
# ❶ 全てのデータベースやアカウント情報をリストア
-bash-4.2$ mysql --user=root --password=password < all_dbs_20200105.sql
# ❶ dropデータベースを含まない
-bash-4.2$ psql -f all_databases_20200105.sql postgres
# ❷ dropデータベースを含む (リストア時はpostgresデータベースに接続)
-bash-4.2$ psql -f all_databases_with_drop_20200105.sql postgres
-bash-4.2$ mysql --user=root --password=password < all_dbs_20200105.sql
❶ スキーマは存在していればそのまま、テーブルオブジェクトは存在していれば
dropして再作成してデータをINSERT
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `app` /*!40100 DEFAULT CHARACTER
SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N'
*/;
USE `app`;
DROP TABLE IF EXISTS `FTS_DOC`;
❶ postgres以外のデータベースを削除してリストア
-bash-4.2$ dropdb app
-bash-4.2$ dropdb lc_test
-bash-4.2$ psql -f all_databases_20200105.sql postgres
SET
CREATE DATABASE
ALTER DATABASE
データベース"app"にユーザ"postgres"として接続しました。
❷ psql -f all_databases_with_drop_20200105.sql postgres
-bash-4.2$ psql -f all_databases_with_drop_20200105.sql postgres
SET
SET
SET
DROP DATABASE
DROP DATABASE
DROP ROLE
"pg_dumpall --clean"を指定してバックアップ
を取得しているのでDROPも含まれるのでそのま
まリストアすれば良い。

8. Logical Backup Restore(Specific Schema)
MySQL PostgreSQL
# ❶ 特定スキーマをリストア
-bash-4.2$ mysql -u root -p gis < dbs_20200105.sql
# ❶ dropデータベースを含まないPlainテキストフォーマットのダンプ
-bash-4.2$ psql app < app.dump_plain
# ❷ dropデータベースを含まないバイナリーフォーマットのダンプ
-bash-4.2$ pg_restore -c -d app app.dump
-bash-4.2$ mysql -u root -p gis < dbs_20200105.sql
Enter password:
-bash-4.2$
root@localhost [gis]> show tables;
+---------------+
| Tables_in_gis |
+---------------+
| temp1 |
| tokyo_area |
+---------------+
2 rows in set (0.00 sec)
root@localhost [gis]>
❶ Plainテキストフォーマットのダンプファイルリストア (psqlでリストア)
$ dropdb app
$ createdb -E UTF8 -l ja_JP.UTF-8 -T template0 -O application_role app
$ psql app < app.dump_plain
❷ リストア時に"-c"を指定し事前にオブジェクトを削除 (pg_restoreでリストア)
-bash-4.2$ pg_restore -c -d app app.dump
app=# l
データベース一覧
-[ RECORD 1 ]-----+----------------------
名前 | app
所有者 | postgres
エンコーディング | UTF8
https://www.postgresql.jp/document/11/html/app-pgrestore.html
https://www.postgresql.jp/document/11/html/app-dropdb.html
https://www.postgresql.jp/document/11/html/app-createdb.html
バイナリーフォーマットのダンプにて -cで事前
に対象オブジェクトの削除を指定する事が可能

9. Physical Backup (MySQL)
MySQL
-bash-4.2$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
-bash-4.2$ yum install percona-xtrabackup-24.x86_64
-bash-4.2$ yum install qpress
-bash-4.2$ innobackupex --user root --password root --compress /mnt/log/backup/20200201
<SNIP>
200201 12:47:46 Executing UNLOCK BINLOG
200201 12:47:46 Executing UNLOCK TABLES
200201 12:47:46 All tables unlocked
200201 12:47:46 [00] Compressing ib_buffer_pool to /mnt/data/backup/20200201/2020-02-01_12-47-46/ib_buffer_pool.qp
200201 12:47:46 [00] ...done
200201 12:47:46 Backup created in directory '/mnt/data/backup/20200201/2020-02-01_12-47-46/'
MySQL binlog position: filename 'mysql-bin.000148', position '154', GTID of the last change ''
200201 12:47:46 [00] Compressing /mnt/data/backup/20200201/2020-02-01_12-47-46/backup-my.cnf.qp
200201 12:47:46 [00] ...done
200201 12:47:46 [00] Compressing /mnt/data/backup/20200201/2020-02-01_12-47-46/xtrabackup_info.qp
200201 12:47:46 [00] ...done
xtrabackup: Transaction log of lsn (1023727525908) to (1023727525958) was copied.
200201 12:47:46 completed OK!
データが大きくなるにしたがってバックアップが1時間以上かかることもある場合は、物理バックアップが良いでしょう。（リカバリーも高速!!）
※ 最新情報＆詳細はマニュアルを参照してください
https://www.percona.com/doc/percona-xtrabackup/LATEST/installation/yum_repo.html
https://www.percona.com/doc/percona-xtrabackup/LATEST/xtrabackup_bin/xbk_option_reference.html
https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0059?page=1
※ バックアップやサポートが必要な場合は、MySQLがオフィシャルに提供しているmysqlbackupの利用が良いでしょう。(MySQLのﾊﾞｰｼﾞｮﾝに合わせてmysqlbackupも選択)
https://www.mysql.com/jp/products/enterprise/backup.html
--incrementalオプションを付ける事でフルバック
アップ取得後に差分バックアップを取得する事も可
能。最新版では, xtrabackupコマンドを利用するこ
とを推奨。
左記のように、ログファイルも一緒にバックアップさ
れるので、リストア時にはデータファイルに該当ログ
を適用してから、--copy-backを利用してMySQLのデー
タディレクトリーにリストア

10. Physical Backup (PostgreSQL)
PostgreSQL
-bash-4.2$ psql -c "SELECT pg_start_backup('online_physical_backup');"
pg_start_backup
-----------------
0/D000028
(1 行)
-bash-4.2$ cp -rp /var/lib/pgsql/12/data/ /var/lib/pgsql/physical_backup/
-bash-4.2$ psql -c "SELECT pg_stop_backup();"
NOTICE: 必要なすべての WAL セグメントがアーカイブされました
pg_stop_backup
----------------
0/D000170
(1 行)
-bash-4.2$ cat 12/data/archive/00000001000000000000000D.00000028.backup
START WAL LOCATION: 0/D000028 (file 00000001000000000000000D)
STOP WAL LOCATION: 0/D000170 (file 00000001000000000000000D)
CHECKPOINT LOCATION: 0/D000098
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2020-02-01 17:32:22 JST
LABEL: online_physical_backup
START TIMELINE: 1
STOP TIME: 2020-02-01 17:33:00 JST
STOP TIMELINE: 1
-bash-4.2$ psql app -c "select pg_switch_wal();"
-bash-4.2$ cat /var/lib/pgsql/12/data/postgresql.conf | grep -v ^# | grep restore
restore_command = 'cp /var/lib/pgsql/12/data/archive/%f %p' # placeholders: %p = path of file to restore
Oracleのオンラインバックアップに似ている。
1) pg_start_backup()でバックアップ開始を宣言
2) データファイルをコピー
3) pg_stop_backup()でバックアップを停止
4) pg_switch_wal()で最新データをアーカイブログに記録
リカバリーの為に、postgresql.confにrestore_commandを追記
データフォルダーをまるごと入れ替えて、PostgreSQLを起動
※recovery.confはPostgreSQL12には無く、postgresql.confに統合
-bash-4.2$ cat postgresql.conf | grep -e "recovery_target_time" -e "restore_command"
restore_command = 'cp /var/lib/pgsql/12/data/archive/%f %p'
#restore_command = '' # command to use to restore an archived logfile segment
#recovery_target_time = '' # the time stamp up to which recovery will proceed
#recovery_target_timeline = 'latest' # 'current', 'latest', or timeline ID

11. More Info
pg_dumpall: https://www.postgresql.jp/document/11/html/app-pg-dumpall.html
pg_dump: https://www.postgresql.jp/document/11/html/app-pgdump.html
pg_restore: https://www.postgresql.jp/document/11/html/app-pgrestore.html
dropdb: https://www.postgresql.jp/document/11/html/app-dropdb.html
createdb: https://www.postgresql.jp/document/11/html/app-createdb.html
PITR: https://www.postgresql.jp/document/11/html/continuous-archiving.html
https://www.slideshare.net/uptimejp/postgresql-14108817
https://www.slideshare.net/satock/osc-hokkaido2014-backuprecovery
https://oss-db.jp/amp/dojo/dojo_info_08
mysqldump: https://dev.mysql.com/doc/refman/5.6/ja/mysqldump.html
mysqldump: https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
mysqlpump: https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html
MySQLに関しては、mysqldumpとMySQL5.7にて実装されたmysqlpumpを利用して論理バックアップの取得が可能。
mysqlpumpに関しては、マルチスレッドにてバックアップ可能。
PostgreSQLに関しては、pg_dumpallを利用して全てのデータベースのバックアップ可能、
但しPlainテキストフォーマットのみでダンプ可能。各データベースをダンプする場合は、
pg_dumpでフォーマットを指定してバックアップを取得し、pg_restoreでリストアする事が可能。
それぞれ、-jオプションを指定する事で並列処理が可能。
物理バックアップに関しては、論理バックアップと比較しても柔軟にPITRの対応が可能。

12. 補足:Backup & Replication (MySQL)
-bash-4.2$ zcat ALLDB_20200105.sql.gz | grep -A5 "Position to start replication or point-in-time recovery from"
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.001403', MASTER_LOG_POS=155;
--
-bash-4.2$ cat dbs_20200105.sql | grep -A5 "GTID state at the beginning of the backup"
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '50fca08e-5a35-11e8-a4f2-06db798d79c8:1';
--
Logポジションベースのレプリケーションはここから
レプリケーション開始すればOK
GTIDベースのレプリケーションはここから
レプリケーション開始されるのでリストア後にAUTO
でこのポジションから同期が開始される。

13. 補足:Backup & Replication (PostgreSQL)
-bash-4.2$ systemctl stop postgresql-12
-bash-4.2$ systemctl status postgresql-12
-bash-4.2$ pwd
/var/lib/pgsql/12
-bash-4.2$ rm -rf data/
-bash-4.2$ mkdir data
-bash-4.2$ pg_basebackup -R -h 192.168.56.104 -p 5432 -U replication_user -D "/var/lib/pgsql/12/data"
-bash-4.2$ chown -R postgres:postgres data/
-bash-4.2$ chmod -R 700 data/
pg_basebackupコマンドに-Rオプションを付けて
Slaveにてバックアップを実行
-bash-4.2$ vim postgresql.conf
-bash-4.2$ cat postgresql.conf | grep hot_standby
hot_standby = on # "off" disallows queries during recovery
-bash-4.2$
-bash-4.2$ ls -l standby.signal
-rw-------. 1 postgres postgres 0 1月 11 10:32 standby.signal
[root@CL-SLAVE01 data]# cat postgresql.auto.conf | grep primary_conninfo
primary_conninfo = 'user=replication_user passfile=''/var/lib/pgsql/.pgpass'' host=192.168.56.104 port=5432 sslmode=prefer sslcompression=0
gssencmode=prefer krbsrvname=postgres
PostgreSQL12からは、recovery.confは不要
postgresql.confのhot_standbyをONにしてあげる
だけで、スレーブを開始すれば同期が始まります。