mysqlマスターXtraBackupリカバリ

MySQLマスタスレーブ同期原理MySQLマスタスレーブ同期は、MySQLマスタスレーブレプリケーション(Master-Slave Replication)に基づいて実現され、Master MySQLに設定されたbinlog(オープン状態)により、Slave MySQL上でI/Oスレッドを介してMaster MySQLからbinlogを読み出し、Slave MySQLの中継ログに転送するその後、Slave MySQLのSQLスレッドは、中継ログから中継ログを読み出し、Slave MySQLのデータベースに適用します.これにより、プライマリ・スレーブ・データ同期機能が実現されます.XtraBackupバックアップの原理innobackupexは、バックグラウンドスレッドでInnoDBのログファイルを追跡し続け、InnoDBのデータファイルをコピーします.データファイルのコピーが完了すると、ログのコピースレッドも終了します.これにより、同じ時点にないデータのコピーとバックアップ開始後のトランザクション・ログが得られます.上記の手順を完了すると、InnoDBクラッシュ・リカバリ・コードを使用してトランザクション・ログ(redo log)を実行し、データの一貫性を達成できます.
XtraBackupのメリット:

データベースを停止することなくInnoDBホットスペア

を行う.

インクリメンタルバックアップMySQL

ストリームは、他のサーバ

への送信に圧縮する.

は、プライマリスレーブ同期

を比較的容易に作成することができる.

MySQLバックアップ時にサーバ負荷が増大しない

バックアップには、次の2つのプロセスがあります.

backup、バックアップフェーズ、トランザクション・ログの追跡、およびデータ・ファイルのコピー(物理バックアップ).

preparing、トランザクション・ログを再生し、すべてのデータを同じ時点にし、一貫性のある状態にします.
なぜマスターコピーをするのですか?これは実施する前によく考えなければならない問題だと思います.読み書き分離を実現し、メインライブラリの負荷やデータ分析を軽減するためですか?データセキュリティのためにバックアップ・リカバリを行いますか?マスタースイッチを高可用性にしますか?ほとんどのシーンでは、以上の3つの疑問符が1つのマスターから1つのマスターから解決され、どの生産環境でも少なくとも1つのスレーブライブラリが必要であることをお勧めします.もしあなたの読み取り操作の圧力が特に大きく、1つのマスターから複数のマスターになるならば、異なるslaveで異なる役割を果たすことができます.例えば、異なるインデックスや異なるストレージエンジンを使用することができます.または、バックアップにのみslaveを使用するには、小さなメモリserverを使用します.(もちろんslaveが多すぎるとmasterの負荷やネットワーク帯域幅に圧力がかかりますが、この場合、カスケード・レプリケーション、すなわちA->B->C)mysqlがサポートするレプリケーション・タイプを考慮できます:(1):文ベースのレプリケーション:プライマリ・サーバ上で実行されるSQL文、サーバ上で同じ文を実行します.MySQLのデフォルトでは、文ベースのレプリケーションが採用されており、効率が高い.正確なレプリケーションができないことが判明すると、行ベースのレプリケーションが自動的に選択されます.(2):ローベースのレプリケーション:サーバからコマンドを1回実行するのではなく、変更するコンテンツを過去にレプリケーションする.mysql 5から0サポート開始(3):ブレンドタイプのレプリケーション:デフォルトでは文ベースのレプリケーションが使用され、文ベースの正確なレプリケーションが発見されると、行ベースのレプリケーションが使用されます.レプリケーションのタイプは、非同期レプリケーションと半同期レプリケーションに分けることもできます.通常は非同期です.つまり、マスターライブラリがCommitを実行した後、マスターライブラリがBinlogログに書き込まれた後、クライアントに正常に戻ります.Binlogログがスレーブライブラリに転送されるのを待つ必要はありません.マスターライブラリがダウンタイムすると、ログが失われる可能性があります.一方、半同期レプリケーションは、ライブラリからBinlogトランザクションが受信され、Relay Logに正常に書き込まれるのを待ってから、Commit操作がクライアントに正常に返されます.このように半同期は、トランザクションが正常にコミットされた後に少なくとも2つのログが記録されることを保証し、1つはメインライブラリBinlog上にあり、もう1つはスレーブライブラリのRelay Log上にあり、データの完全性をさらに保証する.半同期レプリケーションは、プラグインsemisync_を使用して、プライマリスレーブネットワークRTT(往復遅延)に大きく依存します.master/semisync_slave形式が存在する.補足:

mysql 5.7はマルチソースレプリケーションを開始し、この特性は同時に多くのmysqlインスタンスを持つのに役立ち、アリクラウドRDS(移行)は同様の方法を実現した.

MySQL 5.6.2から始まり、mysql binlogはchecksumチェックをサポートし、5.6.6はデフォルトで有効(CRC 32)であり、mysqlレプリケーションを実現するシーンのシミュレーションに影響を与える.

MySQLレプリケーション・テクノロジーには、(1)データ分散(Data distribution)(2)ロード・バランシング(load balancing)(3)バックアップ(Backups)(4)高可用性とフォールト・トレランス・ラインHigh availability and failoverが次のようにしてXtraBackupバックアップを行うには、まずmysqlがデータから同期し、mysqlがプライマリmysqlのデータをリアルタイムで同期することが特徴です.ここで、通常、マスターmsyqlはmysqlバージョンと同じか、マスターmsyqlがmysqlバージョンより高くないことが要求されます(バージョンクエリー>select version()).一般的に安定した方法は、mysqlバージョン間のbinlog(バイナリログ)フォーマットが異なる場合があり、同期異常を引き起こす可能性があるため、バージョンを同じにすることです.

     mysql> select version();
+------------+
| version()  |
+------------+
| 5.6.35-log |
+------------+
1 row in set (0.00 sec)
ip   ：192.168.212.11 
    ：MariaDB [(none)]> select version();
+----------------+
| version()      |
+----------------+
| 10.2.6-MariaDB |
+----------------+
1 row in set (0.00 sec)
ip   ：192.168.212.10 
   ：
mysql> grant replication slave on *.* to 'ff'@'192.168.212.10' identified by 'chylinux';
Query OK, 0 rows affected (0.09 sec)
（               ）
   ：（             ）
           （  ）       （  ）
[root@chy01 ~]# rpm -ivh http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
  http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm
  ：/var/tmp/rpm-tmp.tIRhy2:  V4 DSA/SHA1 Signature,    ID cd2efd2a: NOKEY
   ... ################################# [100%]
    /  ...
1:percona-release-0.1-3 ################################# [100%]
(  rpm  yum    )
[root@chy01 ~]# yum list | grep percona
[root@chy01 ~]# yum install percona-xtrabackup
（        ）
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'chy'@localhost identified by 'aminglinux';
Query OK, 0 rows affected (0.00 sec)
（               ）
mysql> flush privileges;
Query OK, 0 rows affected (0.01 sec)
（  mysql）
[root@chy01 ~]# mkdir /data/backup
(  backup  ，    mysql      )
[root@chy01 ~]# ls -l /data/backup/
    4
drwx------ 9 root root 4096 9    2 18:08 2017-09-02_18-08-29
（         ）
[root@chy01 backup]# tar -zcvf 2017-09-02_18-08-29.tar.gz 2017-09-02_18-08-29
[root@chy01 backup]# du -sh 2017-09-02_18-08-29.tar.gz
540K    2017-09-02_18-08-29.tar.gz
[root@chy01 backup]# rsync -avP /data/backup/2017-09-02_18-08-29.tar.gz 192.168.212.10:/data/backup/
[email protected]'s password:
sending incremental file list
2017-09-02_18-08-29.tar.gz
      551406 100%   40.40MB/s    0:00:00 (xfer#1, to-check=0/1)
sent 3090 bytes  received 4531 bytes  1172.46 bytes/sec
total size is 551406  speedup is 72.35
（ rsync    ）
   （           +     ）
[root@chy ~]# mkdir /data/backup
（              ）
[root@chy ~]# ls /data/backup/
2017-09-02_18-08-29.tar.gz
（          ）
[root@chy ~]# du -sh /data/backup/2017-09-02_18-08-29.tar.gz
540K    /data/backup/2017-09-02_18-08-29.tar.gz
（    ）
[root@chy backup]# tar -xzvf /data/backup/2017-09-02_18-08-29.tar.gz
（   ）
[root@chy backup]# innobackupex --use-memory=512M --apply-log 2017-09-02_18-08-29
（     ）
[root@chy ~]# /etc/init.d/mariadb stop
Stopping mariadb (via systemctl):                          [      ]
（     ，        ）
[root@chy backup]# rm -rf /data/mariadb/
[root@chy backup]# mkdir /data/mariadb
[root@chy backup]# chown mysql1:mysql1 /data/mariadb
[root@chy backup]# innobackupex --defaults-file=/etc/my.cnf --datadir=/data/mariadb/  --use-memory=512M  --copy-back 2017-09-02_18-08-29
（                ，innobackupex version 2.3.9 based on MySQL server 5.6.24 Linux (x86_64) (revision id: fde0e3e)
Error: datadir must be specified.
（             datadir   ，          ）
[root@chy backup]# ls /data/mariadb/
db1      ib_logfile0  mysql   performance_schema  xtrabackup_binlog_pos_innodb  zhucong
ibdata1  ib_logfile1  mysql2  test                xtrabackup_info               zrlog
（         ）
[root@chy backup]# /etc/init.d/mariadb start
Starting mariadb (via systemctl):  Warning: mariadb.service changed on disk. Run 'systemctl daemon-reload' to reload units.
                                                           [      ]
[root@chy backup]# systemctl daemon-reload
[root@chy backup]# /etc/init.d/mariadb start
Starting mariadb (via systemctl):                          [      ]