Mysqlのインクリメンタルバックアップおよびポイント・イン・タイム・ポイント・ベースのリカバリ

3562 ワード

データベース開発ツール

インクリメンタルバックアップの利点は、重複データがなく、バックアップ量が少なく、時間が短いことです.欠点も明らかで、前回の完全バックアップと完全バックアップ後のすべての増分バックアップが必要で、リカバリを反転し、操作が煩雑である.

Mysqlではインクリメンタル・バックアップの方法は提供されていませんが、バイナリ・ログで間接的にインクリメンタル・バックアップを実現できます.

バイナリ・ログバックアップの意味は次のとおりです.1)バイナリ・ログには、データベースを更新または更新する可能性のあるすべてのログ・ファイルが保存されています.2)バイナリ・ログは、Mysqlサーバを起動した後に記録を開始し、ファイルがmax_に達した後に記録を開始します.binlog_sizeが設定したサイズまたは受信したflush logsコマンドの後、新しいログファイルを再作成します.3)flush logsメソッドをタイミングよく実行して新しいログを再作成し、バイナリファイルシーケンスを生成し、これらのログを安全な場所に保存するだけで、1つの期間のインクリメンタルバックアップが完了します.

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

Mysqlのバイナリログ機能

# vim /etc/my.cnf
    [mysql]
    log-bin=mysql-bin    // [mysql]    
# systemctl restart mysqld          //      
（  usr/local/mysql/data/        mysql-bin.000001     ）

を開く

flush-logs前回から現在までのデータおよび操作を前回生成したバイナリファイルに保存し、同時に別の新しいバイナリファイル

    # mysqldump -u root -p school > /opt/school.sql   //        school
    # mysqladmin -u root -p flush-logs  //              
    （  usr/local/mysql/data/        mysql-bin.000002     ）

を生成する.

バイナリファイルの内容を表示する

    # mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002

増分回復

インクリメンタル・リカバリのシナリオ:1)人為的なSQL文がデータベースを破壊した2)次のフル・バックアップを行う前にシステム障害が発生してデータベースのデータが失われた3)プライマリ・スレーブ・アーキテクチャで、プライマリ・ライブラリのデータに障害が発生した.

データロスの状況によって2種類に分けられる:1)完全バックアップ後に変更するデータのみが失われた2)完全バックアップ後にすべてのデータが失われた

フルバックアップ後に変更されたデータ復旧

# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
（             ，              ）

が失われました.

完全バックアップを失った後のすべてのデータリカバリ

# mysql -u root -p school < /opt/school.sql 
# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000002 | mysql -u root -p
（             ，              ）

インクリメンタルバックアップの原理をまとめます.まず、mysqldumpを毎週使用してライブラリ全体を完全にバックアップし、ライブラリ全体のバックアップの時点以降、flush logsを毎日使用して新しいバイナリファイルを生成し、バイナリファイルは毎日データベースの操作が変化する内容を保存し、内容は重複しません.毎週のバックアップライブラリ全体に毎日のバイナリバックアップファイルを加えることで、データベースの現在のデータ状態に相当します.

時点と位置に基づくデータ復旧

バイナリ・ログを使用すると、実行中に誤った操作でテーブルを削除するなど、時点と位置に基づくリカバリを実現できます.

バイナリ・ログの時間または位置リカバリを表示するときに、このエラー・オペレーションをスキップできます.

図のようにzhangsan

を誤って削除しました

mysqladmin-u root-p flush-logsさんバイナリファイル

次に、このバイナリファイルが誤って動作する時点、位置、および正しく動作する時点、位置

を表示する.

mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000005

      
# mysql -u root -p
> use school;     
> drop table info；

順次回復

# mysqldump -u root -p school > /opt/school.sql
# mysqlbinlog --no-defaults mysql-bin.000001 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000002 | mysql -u root -p 
# mysqlbinlog --no-defaults mysql-bin.000003 | mysql -u root -p
# mysqlbinlog --no-defaults mysql-bin.000004 | mysql -u root -p

時間ベースのリカバリ

エラー時間

# mysqlbinlog --no-defaults --stop-datetime='2018-07-03 18:19:49' /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p
# mysqlbinlog --no-defaults --start-datetime='2018-07-03 18:22:21' /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p

をスキップ

位置ベースのリカバリ

エラー位置

# mysqlbinlog --no-defaults --stop-position='347' /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p
# mysqlbinlog --no-defaults --start-position='395' /usr/local/mysql/data/mysql-bin.000005 | mysql -u root -p

をスキップ
転載先:https://blog.51cto.com/13630803/2135741

org.hibernate.HibernateException: Wrong column type

C++GUI Programming with Qt 4-10.4カスタムエージェント(delegate)の実装