MySQL が増分バックアップとリカバリを導入

#無料学習の推奨事項: mysql ビデオ チュートリアル

記事ディレクトリ

1. MySQL 増分バックアップ
• 1. 増分バックアップの概念
  • 1.1 増分を使用する理由バックアップ
    • 1.2 増分バックアップの特徴
  2. 増分バックアップの例
2. MySQL 増分リカバリ
• 1. 増分リカバリのシナリオ
  • 2. 完全バックアップを失った後に変更されたデータのリカバリ手順
  • 3. 完全バックアップ後の損失すべてのデータのリカバリ手順
  • 4. 時点および場所ベースのリカバリ
  • 4.1 時点ベースのリカバリ
    • 4.1 場所ベースの操作
  5. エンタープライズ バックアップ戦略を指定するためのアイデア

---

##1. MySQL 増分バックアップ

#増分バックアップ完全バックアップに基づいてバックアップ ファイルのサイズを削減できるため、バックアップとリカバリが高速化されます。

1. 増分バックアップの概念

1.1 増分バックアップを使用する理由

前の章で、完全バックアップには 2 つの方法があると述べました。1 つは tar を使用してデータ ファイルをパッケージ化する方法で、もう 1 つは

フル バックアップには mysqldump を使用します。

• フル バックアップの問題点は一目瞭然です。毎回すべてのデータ内容がバックアップされ、バックアップ データには大量の重複データが存在します。そして、フル バックアップの時間バックアップとリカバリは非常に時間がかかります
  
完全バックアップの問題を解決するには、増分バックアップを使用します。増分バックアップとは、最後のバックアップ以降に追加または変更されたファイルまたはコンテンツをバックアップすることです
• 1.2 増分バックアップの特徴

増分バックアップの利点は、重複データがなく、バックアップ容量が小さく、時間が短いことです

欠点も明らかで、リストアするには最後の完全バックアップと完全バックアップ後のすべての増分バックアップが必要であり、すべての増分バックアップは 1 つずつリストアされるため、操作が複雑になります。直接的な増分バックアップ方法は提供していませんが、MySQL のバイナリ ログ (バイナリ
• ログ)を通じて間接的に増分バックアップを実現できます。
• バックアップにおけるバイナリ ログの意味は次のとおりです:
  

バイナリ ログは、データベースを更新する、または更新される可能性のあるすべての操作を保存します。

バイナリ ログは、MySQL サーバーの起動後に記録を開始し、ファイルがによって設定されたサイズに達すると再作成されます。ログ ファイル

フラッシュ ログ メソッドを定期的に実行して、新しいログを再作成し、バイナリ ファイル シーケンスを生成し、これらのログを時間内に安全な場所に保存するだけで完了します。一定期間の増分バックアップ
3. 2. 増分バックアップの例

バイナリログ機能を有効にする

vim /etc/my.cnf...[mysqld]log-bin=mysql-binbinlog_format = MIXED#指定二进制日志(binlog)的记录格式为 MIXEDsystemctl restart mysqld.service#重启服务cd /usr/local/mysql/datals -l /usr/local/mysql/data/mysql-bin.*#查看二进制文件#二进制日志(binlog)有3种不同的记录格式：STATEMENT(基于SQL语句)、ROW(基于行)、MIXED(混合模式)#默认格式是 STATEMENT

サーバーの負荷が軽い時間帯、またはバックアップのためのユーザーのアクセスが少ない時間帯を毎週選択してください

mysqldump -uroot -p123123 SCHOOL CLASS01 > /opt/SCHOOL_CLASS01_$(date +%F).sql#对表进行完全备份mysqldump -uroot -p123123 --all-databases SCHOOL > /opt/SCHOOL_$(date +%F).sql#对库进行完全备份crontab -e#也可以使用计划性任务来执行30 3 * * 3 mysqldump -uroot -p123123 SCHOOL CLASS01 > /opt/SCHOOL_CLASS01_$(date +%F).sql30 3 * * 3 mysqldump -uroot -p123123 --all-databases SCHOOL > /opt/SCHOOL_$(date +%F).sql每周三的凌晨 3:00 对数据库和表进行完全备份

増分バックアップ操作を毎日実行して新しいバイナリ ログ ファイルを生成できるため、新しいデータを挿入した後、新しいバイナリ ファイルはデータベースの変更

ls /usr/local/mysql/datamysqladmin -uroot -p123123 flush-logs

3. ##データの追加または変更をシミュレートするために新しいデータを挿入します
#

use SCHOOL;insert into CLASS01 values(3,'wangsan','woman','games');insert into CLASS01 values(4,'wangsi','man','runing');select * from CLASS01;

新しいバイナリ ファイルを生成し、その内容を表示します
4. #

   cd /usr/local/mysql/data/lsmysqladmin -uroot -p123123 flush-logs

#

cp mysql-bin.000002 /opt/#将记录变更的二进制文件02复制至/opt目录下cd /opt/lsmysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002#使用64位编码机制去解码，按行读取详细内容

#2. MySQL 増分リカバリ

増分リカバリは完全リカバリ操作よりも面倒です
各増分バックアップは個別のものであり、データは繰り返されないため、より正確に制御する必要があります

---

1. 増分リカバリのシナリオ

• 当数据发送错误时，应根据实际情况选择使用完全备份恢复，还是增量备份
• 增量备份的场景是：
  • 人为的 SQL 语句破坏了数据库
  • 在进行下一次全备之前发送系统故障导致数据库数据丢失
  • 在主从架构中，主库数据发送了故障
• 根据数据丢失的情况可以分为两类：
  • 只丢失了完全备份之后更改的数据
  • 完全备份之后丢失所有的数据

2.丢失完全备份之后更改的数据的恢复步骤

• 当完全备份之后更改的数据丢失，需要把完全备份之后的所有增量备份文件逐个恢复
• 步骤如下：

mysql -uroot -p123123use SCHOOL;delete from CLASS1 where id=3;delete from CLASS1 where id=4;#删除插入的两条数据，模拟完全备份后数据丢失的故障select * from CLASS01;#检查quitmysqlbinlog --no-defaults /opt/mysql-bin.000002 | mysql -uroot -p123123#使用二进制文件进行恢复操作mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"#检查表内容是否恢复

3.完全备份之后丢失所有数据的恢复步骤

• 当完全备份和增量备份之后，所有的数据丢失，需要把完全备份和所有增量备份文件逐个恢复
• 步骤如下：

mysql -uroot -p123123use SCHOOL;drop table CLASS01;#直接删除整个表，假设完全备份后所有数据都丢失了quitmysql -uroot -p123123 SCHOOL <p><img src="https://img.php.cn/upload/article/000/000/052/c368a93d80781ae407afafe02a2ac327-11.png" alt="MySQL が増分バックアップとリカバリを導入"><br><img src="https://img.php.cn/upload/article/000/000/052/1481568b3321e7dca79c49d509572b7b-12.png" alt="MySQL が増分バックアップとリカバリを導入"></p><p><strong>4. 基于时间点与位置的恢复</strong></p>

• 利用二进制日志可实现基于时间点与位置的恢复，例如由于误操作删除了一张表，这时完全恢复是没有用的
• 因为日志里还有误操作的语句，我们需要的是恢复到误操作之前的状态，然后跳过误操作的语句，再恢复后面操作的语句

4.1 基于时间点的恢复

• 基于时间点的恢复，就是将某个起始时间的二进制文件导入数据库中，从而跳过某个发生错误的时间点实现数据的恢复
• 使用 mysqlbinlog 加上 --stop-datetime 选项，表示在哪个时间点结束，后面误操作的语句不执行
• –start-datetime 选项表示执行后面的语句
• 结合使用它们就可以跳过误操作的语句，完成恢复工作
• 需要注意的是，二进制文件中保存的日期格式需要调整为用“-”分割

#恢复用户“wangsan”的数据，而不恢复“wangsi”mysql -uroot -p123123 -e "truncate table SCHOOL.CLASS01;"mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"mysqlbinlog --no-defaults --stop-datetime='2021-02-06 15:58:39' /opt/mysql-bin.000002 |mysql -uroot -p123123mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"

#恢复“wangsi”的数据mysqlbinlog --no-defaults --start-datetime='2021-02-06 15:58:39' /opt/mysql-bin.000002 |mysql -uroot -p

4.1 基于位置的操作

• 基于位置的恢复，就是使用基于时间点的恢复
• 可能会出现在一个时间点里既同时存在正确的操作又存在错误的操作，基于位置是一种更为精确的恢复方式

mysqlbinlog --no-defaults --stop-position='609' /opt/mysql-bin.000002 | mysql -uroot -p#使用64位编码机制去解码并按行读取二进制文件02（增量备份）的详细内容......略

#仅恢复“1810”之前的数据，即不恢复“wangsi”的数据mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"mysql -uroot -p123123 -e "truncate table SCHOOL.CLASS01;"mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"mysqlbinlog --no-defaults --stop-position='1810' /opt/mysql-bin.000002 | mysql -uroot -pmysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"

#仅恢复“wangsi”的数据，跳过“wangsan”的数据恢复，即仅有第四条记录mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"mysqlbinlog --no-defaults --start-position='1810' /opt/mysql-bin.000002 | mysql -uroot -p123123mysql -uroot -p123123 -e "select * from SCHOOL.CLASS01;"

5. 指定企业备份策略的思路

• 指定企业备份策略要根据企业数据库的实际读写的频繁性与数据的重要性进行
• 数据更新频繁，则应该进行较为频繁的备份
• 数据较为重要，则在有适当更新时进行备份
• 在数据库压力小的时段进行全备，如一周一次，然后每天增备
• 根据公司的规模，中小公司可一天一次全备，大公司可每周一次全备，每天进行一次增备，并且尽量为企业实现主从复制架构

相关免费学习推荐：mysql数据库(视频)

以上がMySQL が増分バックアップとリカバリを導入の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。