目次
1. ステートメント: SQL ステートメントベースのレプリケーション (ステートメントベースのレプリケーション、SBR)
2. 行: 行ベースのレプリケーション (行ベースのレプリケーション、RBR)
3. 混合: 混合モードのレプリケーション (混合ベースのレプリケーション、MBR)
1. mysql で show binlog events を使用して表示します。
2. シェルで mysqlbinlog を使用して表示します。
1. bin ログを使用してデータを復元する
1. bin ログの 3 つの形式
1. ステートメント: SQL ステートメントベースのレプリケーション (ステートメントベースのレプリケーション、SBR)
- データを変更するすべての SQL は binlog に記録されます。
- 利点:各行の変更を記録する必要がないため、binlog ログの量が削減され、IO が節約され、パフォーマンスが向上します。ただし、アプリケーションの SQL 状況に応じて、行と比較してステートメントによってパフォーマンスとログの量がどの程度節約されるかに注意してください。通常、ROW形式の同じレコードの変更や挿入によって生成されるログの量は、Statementによって生成されるログの量よりも少なくなりますが、条件付き更新操作、テーブル全体の削除、テーブルの変更などの操作を考慮すると、ROW形式の方がログの量が少なくなります。大量のログが生成されるため、ROW 形式のログを使用するかどうかを検討する場合は、アプリケーションの実際の状況、ログ量がどの程度増加するか、およびそれによって生じる IO パフォーマンスの問題に基づいて決定する必要があります。
- 欠点:実行ステートメントのみが記録されるため、これらのステートメントがスレーブ上で正しく実行されるようにするには、各ステートメントの実行時に関連情報も記録し、すべてのステートメントがスレーブ上で同じ結果を確実に取得できるようにする必要があります。それらはマスター側で実行されます。さらに、特定の機能をスレーブとマスターで一貫させる必要がある場合、関連する多くの問題が発生します。
2. 行: 行ベースのレプリケーション (行ベースのレプリケーション、RBR)
- MySQL のバージョン 5.1.5 では、行レベルのレプリケーションのサポートが開始されただけで、SQL ステートメントのコンテキストの関連情報は記録されず、どのレコードが変更されたかが保存されるだけです。
- 利点:バイナリログには、実行された SQL ステートメントのコンテキスト関連情報を記録する必要はなく、レコードの変更内容のみを記録する必要があります。したがって、行レベルのログには、データ変更の各行の詳細が非常に明確に記録されます。また、特定の場合にストアド プロシージャ、関数、またはトリガーの呼び出しとトリガーが正しくコピーされないという問題は発生しません。
- 欠点:実行されたすべてのステートメントがログに記録される場合、それらは各行レコードの変更として記録されるため、大量のログ内容が生成される可能性があります。ただし、新しいバージョンの MySQL は行レベル モードを最適化します。すべての変更が行レベルで記録されるわけではありません。たとえば、テーブル構造が変更されると、ステートメント モードで記録されます。SQL ステートメントが実際に更新またはdelete など。データを変更するステートメントでは、すべての行の変更が記録されます。
3. 混合: 混合モードのレプリケーション (混合ベースのレプリケーション、MBR)
- バージョン 5.1.8 以降、MySQL は混合形式を提供します。これは、実際には Statement と Row の組み合わせです。
- 混合モードでは、一般的なステートメント変更ではステートメント形式を使用してバイナリログを保存します。一部の関数とステートメントがマスター/スレーブレプリケーション操作を完了できない場合、バイナリログの保存に行形式が使用されます。MySQL はそれぞれに応じてレコードを異なる方法で処理します。実行された特定の SQL ステートメントのログ形式、つまりステートメントと行のいずれかを選択します。
4. 表示モードとモード変更
mysql> show variables like 'binlog_format'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | MIXED | +---------------+-------+ 1 row in set, 1 warning (0.00 sec) mysql> set binlog_format=mixed; Query OK, 0 rows affected (0.00 sec)
2. bin ログ戦略を構成する
設定ファイルに追加します
[mysqld] # 指定 binary log 的路径和名称 log-bin="/var/lib/mysql/binlog" # 存活时间 binlog_expire_logs_seconds=60000 # 单个 binlog 文件的最大大小 max_binlog_size=100M # binlog的日志策略 binlog_format=mixed;
3. bin ログ ファイルのリストを取得します。
mysql> show binary logs; +------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +------------------+-----------+-----------+ | IU077-bin.000038 | 157 | No | | IU077-bin.000039 | 1400 | No | | IU077-bin.000040 | 157 | No | | IU077-bin.000041 | 333 | No | | IU077-bin.000042 | 157 | No | | IU077-bin.000043 | 157 | No | | IU077-bin.000044 | 157 | No | | IU077-bin.000045 | 157 | No | | IU077-bin.000046 | 157 | No | | IU077-bin.000047 | 157 | No | | IU077-bin.000048 | 180 | No | | IU077-bin.000049 | 180 | No | | IU077-bin.000050 | 157 | No | | IU077-bin.000051 | 157 | No | +------------------+-----------+-----------+
4 番目に、新しい bin ログ ファイルを生成します。
次の 3 つの状況では、新しい bin ログが生成される可能性があります。
- サーバーを停止または再起動するたびに、サーバーはログ ファイルを次のログ ファイルに記録し、MySQL は再起動時に新しいログ ファイルを生成し、ファイルのシーケンス番号が増加します。
- ログ ファイルが max_binlog_size (デフォルト値 1G) システム変数設定の上限を超えると、新しいログ ファイルも生成されます (ここで、大規模なトランザクションを使用している場合、バイナリ ログが max_binlog_size を超え、新しいログ ファイルでは、すべてのトランザクションがバイナリ ログに書き込まれます。これは主にトランザクションの整合性を確保するためです)
- ログを手動でフラッシュしてログを更新すると、新しいログ ファイルが生成されます。
mysql> flush logs; Query OK, 0 rows affected (0.07 sec)
5. ログの内容を表示する
1. mysql で show binlog events を使用して表示します。
特定のログの内容を表示します。
mysql> show binlog events in 'IU077-bin.000052'; +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+ | IU077-bin.000052 | 4 | Format_desc | 1 | 126 | Server ver: 8.0.30, Binlog ver: 4 | | IU077-bin.000052 | 126 | Previous_gtids | 1 | 157 | | | IU077-bin.000052 | 157 | Anonymous_Gtid | 1 | 234 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | IU077-bin.000052 | 234 | Query | 1 | 345 | create database db_16 /* xid=20 */ | | IU077-bin.000052 | 345 | Anonymous_Gtid | 1 | 422 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | IU077-bin.000052 | 422 | Query | 1 | 555 | use `db_16`; create table tb1(id int, lname varchar(20)) /* xid=24 */ | | IU077-bin.000052 | 555 | Anonymous_Gtid | 1 | 634 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | IU077-bin.000052 | 634 | Query | 1 | 710 | BEGIN | | IU077-bin.000052 | 710 | Table_map | 1 | 768 | table_id: 92 (db_16.tb1) | | IU077-bin.000052 | 768 | Write_rows | 1 | 821 | table_id: 92 flags: STMT_END_F | | IU077-bin.000052 | 821 | Xid | 1 | 852 | COMMIT /* xid=26 */ | | IU077-bin.000052 | 852 | Rotate | 1 | 899 | IU077-bin.000053;pos=4 | +------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+ 12 rows in set (0.00 sec)特定の位置から表示を開始するように指定します
mysql> show binlog events in 'IU077-bin.000052' from 710; +------------------+-----+------------+-----------+-------------+--------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +------------------+-----+------------+-----------+-------------+--------------------------------+ | IU077-bin.000052 | 710 | Table_map | 1 | 768 | table_id: 92 (db_16.tb1) | | IU077-bin.000052 | 768 | Write_rows | 1 | 821 | table_id: 92 flags: STMT_END_F | | IU077-bin.000052 | 821 | Xid | 1 | 852 | COMMIT /* xid=26 */ | | IU077-bin.000052 | 852 | Rotate | 1 | 899 | IU077-bin.000053;pos=4 | +------------------+-----+------------+-----------+-------------+--------------------------------+ 4 rows in set (0.00 sec)現在書き込まれているログのステータスを表示します。
mysql> show master status\G *************************** 1. row *************************** File: IU077-bin.000053 Position: 157 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1 row in set (0.00 sec)2. シェルで mysqlbinlog を使用して表示します。
mysqlbinlog -v 日志文件的路径 例如： mysqlbinlog -v /usr/local/mysql/data/binlog.000010
6. bin ログを使用してデータを復元する
知らせ：
bin ログは、ロールバックによってデータを回復するのではなく、SQL ステートメントを再実行することによってデータを回復します。
1.pos経由で復元する
方法 1: mysql ログインを実行し、シェルで切り替える
mysqlbinlog --start-position=100 --stop-position=300 --database=数据库名 binlog文件 | mysql -uroot -p密码 -v 数据库名方法 2: .sql サフィックスが付いたスクリプトを生成し、mysql でスクリプトを実行する
# 第一步：先生成sql脚本 mysqlbinlog --start-position=100 --stop-position=300 --database=数据库名 binlog文件 > resume.sql # 第二步：在sql中执行该脚本 mysql> source 脚本路径/脚本名称2. 時間の経過による回復
位置を日時またはタイムスタンプに変更します
2. 論理バックアップとリカバリ
1. mysqldumpツールで論理バックアップを実現
基本操作:
# 备份单个数据库 mysqldump -uroot -p密码 database_1 > database_1.sql # 备份全部数据库 mysqldump -uroot -p密码 --all-databases # 或者 mysqldump -uroot -p密码 --Aより詳細な操作:
パラメータ 効果 --databases または -B データベースの一部をバックアップする データベース名の後にテーブル名が続きます 部分テーブルのバックアップ --where="id < 10" バックアップテーブルの部分データ --ignore-table=データベース.テーブル名 このテーブルをバックアップしないでください --no-create-info 構造はバックアップされず、データのみがバックアップされます - データなし データをバックアップしないでください
2. ロジックの回復
1. シェルで復元する
mysql -uroot -p密码 数据库名 < .sql脚本2.mysqlで復元する
mysql> source 脚本路径/脚本名称.sql
3. 物理的なバックアップとリカバリ
1. 物理バックアップ
1. バックアップ プロセス中にデータベースが変更されないように、最初にデータベースをロックします。
mysql> flush tables with read lock;2. 物理コピーのバックアップ
cp -r database_1 /backup/database_1_bak3. データベースのロックを解除します（ロックの解除を忘れないでください）
mysql> unlock tables;2. 身体の回復
1. 身体の動き
cp 数据库 路径/名称2.mysqlサービスを再起動します。
systemctl restart mysql3. mysql ユーザーに権限を付与します。
chown -R mysql.mysql /var/lib/mysql/数据库名
4 番目に、データベースのエクスポートとインポート
1. エクスポート
1. INTO OUTFILE によるエクスポート
1. まずデータベースがエクスポートできるかどうかを確認します
mysql> show variables like '%secure%'; +--------------------------+------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------+ | require_secure_transport | OFF | | secure_file_priv | D:\Program Files (x86)\MySQL\Data 8.0\Uploads\ | +--------------------------+------------------------------------------------+2. エクスポートを開始する
mysql> select * from tb1 INTO OUTFILE "D:\Program Files (x86)\MySQL\Data 8.0\Uploads\tb1.txt";2. mysqldump を使用してエクスポートする
txtファイルとSQLスクリプトを同時に生成
mysqldump -uroot -p密码 -T "路径" 数据库名 表名;3. mysql コマンドを使用してエクスポートします。
クエリの内容を txt ファイルにエクスポートします
mysql -uroot -p密码 --execute="select * from tb1;" 数据库名 > 名字.txt;2、インポート
1. LOAD DATA INFILEのインポート
mysql> LOAD DATA INFILE 'txt文本文件' INTO TABLE dbname.tbname;
5. 誤って削除したデータベースの回復手順
- 最新の完全バックアップを取得します。
- 完全バックアップを使用して一時ライブラリを復元します。
- フルバックアップ後にbin logログを取り出します。
- ログ内の誤操作SQLを削除し、他のステートメントを一時ライブラリに適用します。
- 応答が完了したら、一時ライブラリをメイン ライブラリに復元します。