Heim > Datenbank > MySQL-Tutorial > So verwenden Sie Xtrabackup für die inkrementelle Sicherung von MySQL

So verwenden Sie Xtrabackup für die inkrementelle Sicherung von MySQL

WBOY
Freigeben: 2023-05-30 14:50:06
nach vorne
1368 Leute haben es durchsucht

Verwenden Sie Xtrabackup für die inkrementelle MySQL-Sicherung

Jetzt wurde die xtrabackup-Version auf 8.0 aktualisiert, sie wird jedoch nur für mysql8.0 unterstützt, aber 2.4 hat im Vergleich zum vorherigen 2.1 große Änderungen erfahren: Alle Funktionen von innobackupex sind in xtrabackup integriert, und das ist so nur eine binary, und aus Kompatibilitätsgründen dient innobackupex als Softlink von xtrabackup, also xtrabackup Unterstützt jetzt nicht-Innodb-Tabellensicherungen und Innobackupex wird in der nächsten Version entfernt (bereits in 8.0 entfernt). Es wird empfohlen, innobackupex durch xtrabackup. Es gibt auch einige andere neue Funktionen. Weitere Anweisungen finden Sie in der neuen Version von <code>xtrabackup. mysql8.0才有支持, 我们这还是使用2.4, 但是2.4相比之前的2.1有了比较大的变化:innobackupex 功能全部集成到 xtrabackup 里面,只有一个 binary,另外为了使用上的兼容考虑,innobackupex 作为 xtrabackup 的一个软链,即 xtrabackup 现在支持非Innodb表备份,并且 Innobackupex 在下一版本中移除(8.0已经移除了),建议通过xtrabackup替换innobackupex。还有其他的一些新特性,更多的说明可以看xtrabackup新版详细说明。

安装

如果安装需要依赖就把依赖安装一下

wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
sudo apt-get update
sudo apt-get install percona-xtrabackup-24
Nach dem Login kopieren

设置数据库用于备份账户

mysql> CREATE USER &#39;bkpuser&#39;@&#39;localhost&#39; IDENTIFIED BY &#39;123456&#39;;
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO &#39;bkpuser&#39;@&#39;localhost&#39;;
mysql> FLUSH PRIVILEGES;
Nach dem Login kopieren

全量备份

xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/mysql
# 会看到输出
200603 09:55:37 Executing UNLOCK TABLES
200603 09:55:37 All tables unlocked
200603 09:55:37 [00] Copying ib_buffer_pool to /data/backups/mysql/ib_buffer_pool
200603 09:55:37 [00]        ...done
200603 09:55:37 Backup created in directory &#39;/data/backups/mysql/&#39;
200603 09:55:37 [00] Writing /data/backups/mysql/backup-my.cnf
200603 09:55:37 [00]        ...done
200603 09:55:37 [00] Writing /data/backups/mysql/xtrabackup_info
200603 09:55:37 [00]        ...done
xtrabackup: Transaction log of lsn (837940114) to (837940123) was copied.
200603 09:55:37 completed OK!
Nach dem Login kopieren
  • 准备备份

xtrabackup --prepare --target-dir=/data/backups/mysql
Nach dem Login kopieren
  • 复制备份

我这里为了演示全量备份就直接将我博客 mysql 存储的数据目录给移动一下

mv /var/lib/mysql /var/lib/mysql_bak
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/data/backups/mysql  # 这样会保留原始备份 他会将当时读到my.cnf的datadir设置为恢复路径
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./performance_schema/mutex_instances.frm to /var/lib/mysql/performance_schema/mutex_instances.frm
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./performance_schema/events_transactions_history_long.frm to /var/lib/mysql/performance_schema/events_transactions_history_long.frm
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./ibtmp1 to /var/lib/mysql/ibtmp1
200603 10:47:42 [01]        ...done
200603 10:47:42 completed OK!
Nach dem Login kopieren
  • 备份成功 重新启动 博客还能正常访问 哈哈哈哈

# 将恢复目录的属主更改一下
chown -R mysql:mysql mysql
/etc/init.d/mysql start
Nach dem Login kopieren

如果恢复玩不想要备份数据可以使用 xtrabackup --move-back 命令

增量备份

增量是基于已有数据进行备份的,也就行需要先创建一次全量备份,然后记录当时的记录点

  • 创建备份

xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/base
# 基于全量备份进行增量
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base
Nach dem Login kopieren
  • 查看备份类型 确认是增量备份了

root@longing:/data/backups/inc1# cat xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 837943393
to_lsn = 837943393
last_lsn = 837943402
compact = 0
recover_binlog_info = 0
flushed_lsn = 837943402
Nach dem Login kopieren

from_lsn 是备份的起始 LSN,对于增量备份,它必须to_lsn与先前 base 备份的相同。

在这种情况下,您可以看到to_lsn (最后一个检查点LSN)和last_lsn(最后一个复制的LSN)之间存在差异,这意味着在备份过程中服务器上有一些流量。

  • 我们可以测试一下 对第一个增加继续创建增量 创建增量之前先创建几条数据

xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1
Nach dem Login kopieren
  • 准备恢复

已经有3个备份了,我们要先对基础数据进行准备,然后对两个增量进行准备

xtrabackup --user=bkpuser --password=123456 --prepare --apply-log-only --target-dir=/data/backups/base
xtrabackup --user=bkpuser --password=123456 --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1
xtrabackup --user=bkpuser --password=123456 --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2
Nach dem Login kopieren

xtrabackup --apply-log-only 合并除最后一个以外的所有增量时应使用, 一旦准备好,增量备份就与完整备份相同,可以用相同的方式还原它们。

  • 恢复

xtrabackup --copy-back --target-dir=/data/backups/base
Nach dem Login kopieren

中间插入的数据就能看见了,真棒!

提问总结

  • 增量备份步骤

  • 创建基础备份

  • 一定条件进行增量备份创建

  • 对所有备份进行准备 所有增量基于基础备份 相当于合并操作

  • 最后和全量备份一样 直接恢复即可

原理

InnoDB内部会维护一个redo日志文件,我们也可以叫做事务日志文件.事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时,InnoDB会检查数据文件和事务日志,并执行两个步骤:它应用(前滚)已经提交的 事务日志到数据文件,并将修改过但没有提交的数据进行回滚操作。

Xtrabackup 在启动时会记住log sequence number(LSN), 并且复制所有的数据文件。复制过程需要一些时间,所以这期间如果数据文件有改动,那么将会使数据库处于一个不同的时间点。这时,xtrabackup 会运行一个后台进程,用于监视事务日志,并从事务日志复制最新的修改。Xtrabackup 必须持续的做这个操作,是因为事务日志是会轮转重复的写入,并且事务日志可以被重用。所以 xtrabackup 自启动开始,就不停的将事务日志中每个数据文件的修改都记录下来。上面就是 xtrabackup 的备份过程。

为什么最后一次增量备份不用 "--apply-log-only"

最后一次"准备"操作可以不用跳过回滚操作,这样用来恢复的数据文件本地就处理好了,当服务启动后就不会再进入到回滚阶段,如果最后一次使用了这个参数,服务器启动后将进入回滚阶段。所以这个--apply-log-only 只是用来合并增量用的避免下一个增量不可用。 可以参见 参见 man xtrabackup

Installation🎜🎜Wenn die Installation Abhängigkeiten erfordert, installieren Sie die Abhängigkeiten🎜
xtrabackup --user=bkpuser --password=123456 --backup --databases="u_test" --no-timestamp --target-dir=/data/backups/u
xtrabackup --prepare --target-dir=/data/backups/u
Nach dem Login kopieren
Nach dem Login kopieren
🎜Richten Sie die Datenbank für Sicherungskonten ein🎜rrreee🎜Vollständige Sicherung🎜rrreee
  • 🎜Sicherung vorbereiten🎜
rrreee
  • 🎜Sicherung kopieren🎜
🎜Um die vollständige Sicherung zu demonstrieren, werde ich meinen Blog direkt kopieren Verschieben Sie das von MySQL gespeicherte Datenverzeichnis 🎜rrreee
  • 🎜Die Sicherung ist erfolgreich und auf den Blog kann nach dem Neustart normal zugegriffen werden hahahaha 🎜
rrreee🎜Wenn Sie während der Wiederherstellung keine Daten sichern möchten, können Sie den Befehl xtrabackup --move-back verwenden.🎜🎜Inkrementelle Sicherung🎜🎜Die inkrementelle Sicherung basiert auf vorhandenen Daten, daher müssen Sie zuerst ein vollständiges Volume erstellen. Sichern und dann den Aufnahmepunkt zu diesem Zeitpunkt aufzeichnen🎜
  • 🎜Erstellen Sie ein Backup🎜
  • rrreee
      < li>🎜Überprüfen Sie den Sicherungstyp, um zu bestätigen, dass es sich um eine inkrementelle Sicherung handelt🎜
    rrreee🎜from_lsn ist der Startpunkt des Backups LSN. Für inkrementelle Backups muss es mit to_lsn dem vorherigen Basis identisch sein. 🎜🎜In diesem Fall können Sie to_lsn (letzter Prüfpunkt-LSN) und last_lsn (letzter kopierter LSN) sehen. Es gibt einen Unterschied, was bedeutet Während des Sicherungsvorgangs gibt es etwas Datenverkehr auf dem Server. 🎜
    • 🎜Wir können die erste Erhöhung testen und mit der Erstellung von Inkrementen fortfahren. Erstellen Sie einige Daten, bevor Sie Inkremente erstellen🎜
    rrreee< ul-Klasse =" list-paddingleft-2">
  • 🎜Wiederherstellung vorbereiten🎜
🎜Es gibt bereits 3 Backups. Wir müssen zuerst die Grunddaten vorbereiten und dann die beiden Inkremente vorbereiten 🎜rrreee 🎜xtrabackup --apply-log-only sollte verwendet werden, wenn alle Inkremente außer dem letzten zusammengeführt werden. Sobald sie vorbereitet sind, sind inkrementelle Backups dasselbe wie vollständige Backups und können auf die gleiche Weise wiederhergestellt werden. 🎜
  • 🎜Wiederherstellen🎜
rrreee🎜Die in der Mitte eingefügten Daten können sich sehen lassen, großartig!🎜🎜Zusammenfassung der Fragen🎜
  • 🎜Inkrementelle Backup-Schritte🎜
  • 🎜Erstellen Sie ein Basis-Backup🎜
  • < li>🎜Erstellen Sie inkrementelle Backups unter bestimmten Bedingungen🎜
  • 🎜Alle Backups basierend auf Basis-Backups vorbereiten sind äquivalent zu Zusammenführungsvorgängen🎜
  • 🎜Abschließend direkt wiederherstellen Backups. Das ist es🎜

Prinzip

🎜 Eine Redo-Log-Datei wird in InnoDB verwaltet Das Transaktionsprotokoll speichert jede Datensatzänderung der InnoDB-Tabellendaten. Wenn InnoDB startet, überprüft InnoDB die Datendateien und Transaktionsprotokolle und führt zwei Schritte aus: Es wendet festgeschriebene Transaktionsprotokolle auf die Datendateien an (rollforward) und führt ein Rollback geänderter, aber nicht festgeschriebener Daten durch. 🎜🎜Xtrabackup merkt sich beim Start die Log Sequence Number (LSN) und kopiert alle Datendateien. Der Kopiervorgang dauert einige Zeit. Wenn die Datendateien in diesem Zeitraum geändert werden, befindet sich die Datenbank zu einem anderen Zeitpunkt. Zu diesem Zeitpunkt führt xtrabackup einen Hintergrundprozess aus, um das Transaktionsprotokoll zu überwachen und die neuesten Änderungen aus dem Transaktionsprotokoll zu kopieren. Xtrabackup muss diesen Vorgang weiterhin ausführen, da das Transaktionsprotokoll wiederholt abwechselnd geschrieben wird und das Transaktionsprotokoll wiederverwendet werden kann. Daher hat xtrabackup seit dem Start kontinuierlich die Änderungen jeder Datendatei im Transaktionsprotokoll aufgezeichnet. Das Obige ist der Backup-Prozess von xtrabackup. 🎜

Warum verwendet die letzte inkrementelle Sicherung nicht „--apply-log-only“?

🎜Der letzte „Vorbereitungs“-Vorgang muss den Rollback-Vorgang nicht überspringen, sodass die für die Wiederherstellung verwendeten Datendateien nicht übersprungen werden können Wenn der Dienst lokal verarbeitet wird, tritt er nicht erneut in die Rollback-Phase ein. Wenn dieser Parameter zum letzten Mal verwendet wird, tritt der Server nach dem Start in die Rollback-Phase ein. Daher wird dieser --apply-log-only nur zum Zusammenführen von Inkrementen verwendet, um zu vermeiden, dass das nächste Inkrement nicht verfügbar ist. Siehe siehe man xtrabackup🎜

为什么备份完后要准备备份 "prepare"

一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此,此时数据文件仍处理不一致状态。他的作用是使数据文件处于一致性状态,方法是回滚未提交的事务并同步已提交的事务至数据文件。

为什么选择这个做备份?

  • mysqldump 备份缺点

效率较低,备份和还原速度慢,份过程中,数据插入和更新操作会被挂起

  • MySQL 备份工具

跨平台性差,备份时间长,冗余备份,浪费存储空间

  • XtraBackup

备份过程中不锁库表,适合生产环境,由专业组织Percona提供( 改进MySQL分支 )

  • XtraBackup能对表 库进行备份吗?

当然了,只不过博主太懒了,写起来太麻烦了,不过原理都是差不多,操作也差不多,大家自己搞搞!

xtrabackup --user=bkpuser --password=123456 --backup --databases="u_test" --no-timestamp --target-dir=/data/backups/u
xtrabackup --prepare --target-dir=/data/backups/u
Nach dem Login kopieren
Nach dem Login kopieren

还原

  • prepare,利用--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态

  • copy,因为是部分备份,不能直接用--copy-back,只能手动来复制需要的库,也要复制ibdata(数据字典)

  • cp /data/backups/u/ibdata1 /var/lib/mysql/

  • cp -r u/u_test /var/lib/mysql/

Das obige ist der detaillierte Inhalt vonSo verwenden Sie Xtrabackup für die inkrementelle Sicherung von MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Verwandte Etiketten:
Quelle:yisu.com
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage