Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQLとPostgreSQLの基本的なバックアップ比較

564 views

Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

MySQLとPostgreSQLの基本的なバックアップ比較

  1. 1. Backup Requirement RTO(Recovery Time Objective):目標復旧時間 –障害発生時に「どのくらいの時間で復旧させるか?」 RPO(Recovery Point Objective):目標復旧時点 –障害発生時に「どの時点までのデータを復旧させる必要があるか?」 バックアップ計画を立てる為に、先ずは障害発生時のリカバリー要件を検討し方法を選択。
  2. 2. 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でリストア バックアップ & リカバリー方法
  3. 3. 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
  4. 4. 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 含 場合 適宜事前削除利用 等 指定
  5. 5. 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 指定 複数 指定 事 可能 時 選択可能
  6. 6. 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も含まれるのでそのま まリストアすれば良い。
  7. 7. 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で事前 に対象オブジェクトの削除を指定する事が可能
  8. 8. 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のデー タディレクトリーにリストア
  9. 9. 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
  10. 10. 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の対応が可能。
  11. 11. 補足: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 でこのポジションから同期が開始される。
  12. 12. 補足: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にしてあげる だけで、スレーブを開始すれば同期が始まります。

×