単一のMySQLテーブルを復元する手順

休憩中に、眠気を完全に吹き飛ばす電話がかかってきました。「開発者が更新 SQL を書くときに where 条件を追加するのを忘れていました。」このニュースを聞いたら、DBA のクラスメートなら誰でも悪態をつきたくなると思います。幸いなことに、混乱していたのは 1 つのテーブルだけで、DB 内のテーブルを削除しようとする専門家はいませんでした。長い間、単一テーブルのリカバリを行っていませんでしたが、幸い手順はすべて頭に刻み込まれていたため、問題なくリカバリを完了できました。

ここで、自分自身と他の全員に思い出してもらうために、単一テーブル回復の手順と重要なポイントを記録しておきます。

最初のステップ:

復元マシンとして比較的パフォーマンスの高いサーバーを探し、バックアップ プールから最新のバックアップをこの復元マシンに復元します。もちろん、これはバックアップがあり、そのバックアップが利用可能であることを前提としています。 (何だって？バックアップを取っていないって言ったじゃないか。じゃあ寝て自由な空気を楽しんでください。)

注意: この時点では同期を開始せず、必ず非同期状態に保ってください。

追伸: もう 1 つ言いたいことがあります。DBA にとって、バックアップは最も重要なリンクです。バックアップが必要なだけでなく、バ​​ックアップが利用可能かどうかを定期的に確認する必要があります。これは DBA に必要な資質の 1 つです。

ステップ2:

間違った SQL ステートメントと時点を取得するミスを犯した開発者に連絡し、メイン データベースのバイナリ ログからこの SQL ステートメントの実行ポイントを見つけます。具体的な操作例は以下のとおりです

### mysqlbinlog を使用してバイナリ ログをプレーンテキスト SQL ログに変換します。mysqlbinlog mysql-bin.000123 > /data1/000123.sql

### Linux grep コマンドを使用して、「キーワード」に基づいてデータ破損の原因となる SQL の場所を見つけます。cat 000123.sql |grep -C 10 'key word' --color

### 赤い部分は問題のあるSQL、このSQLの開始時刻、次のSQLの開始時刻です。この2つのPOS位置は非常に重要です# 20393709
#131205 20:55:08 サーバー ID 18984603 end_log_pos 20393779 クエリ thread_id=16296016 exec_time=0 error_code=0
タイムスタンプを 1386248108/*!*/ に設定します。
始める
//*!*/;
# 20393779 で
#131205 20:55:08 サーバー ID 18984603 end_log_pos 20394211 クエリ thread_id=16296016 exec_time=0 error_code=0
タイムスタンプを 1386248108/*!*/ に設定します。
テーブル tablename を更新し、names='xxxx' を設定します。
# 20394211 で
#131205 20:55:08 サーバー ID 18984603 end_log_pos 20394238 Xid = 92465981
専念 /*！*/;
# 20394238 で
#131205 20:55:10 サーバー ID 18984603 end_log_pos 20394308 クエリ thread_id=16296017 exec_time=0 error_code=0
タイムスタンプを 1386248110/*!*/ に設定します。
始める

ステップ3:

2番目のステップで取得したpos位置に従って同期関係を開始しますが、問題のあるSQLの前のpos位置で停止する必要がある場合は、次のコマンドを使用します。

### pos 位置は、問題のある SQL の pos 位置と同じです。 begin slave start until master_log_file='mysql-bin.000123',master_log_pos=20393709;

次に、このSQLをスキップして、次のPOS位置への変更を同期します。次のコマンドを使用します。

### pos 位置は、問題のある SQL コミット後の pos 位置と同じです。master を master_log_file='mysql-bin.000123',master_log_pos=20394238; に変更します。

上記の 2 つのコマンドから、2 番目の手順で取得された 2 つの POS 位置が重要であることがわかります。

ステップ4:

メイン データベース上の不要なデータを含むテーブルの名前を変更する目的は 2 つあります。1 つ目は、このテーブルへの書き込みを停止することです (もちろん、これにより業務に一定の影響が生じ、一定期間書き込み失敗のアラームが表示されるため、事前に業務部門に連絡する必要があります)。2 つ目は、リカバリが失敗した場合でも、少なくとも不要なデータを含むテーブルが残っているため、リカバリ操作前の状態にすばやく復元できます。

### メイン データベースでテーブル tablename を tablename_bak に名前変更します。

次に、復元マシンでダンプ操作を実行します。この操作を使用するときは注意してください。テーブルに中国語の文字がある場合は、--default-chararter-set パラメータを追加することを忘れないでください。

mysqldump -uusername -ppassword -S/tmp/mysql.sock dbname テーブル名 --opt> テーブル名.sql

最後に、このファイルをメインライブラリサーバーに転送して、最終的な回復操作を完了します。

### MySQL にログインした後、tablename.sql をソースとして選択できます。

### cmd インターフェース mysql -uusername -ppassword -S/tmp/mysql.sock < tablename.sql を使用することもできます。

もちろん、この手間を回避して以下のコマンドを直接実行することもできますが、私の個人的な習慣では、過去の操作記録と中間結果を保存するので、上記の手順に従って完了します。 こうすることで、いつでも復元できるテキストファイルを保存できるので、より安心です。

### 簡単な方法は、以下の手順に従うことです。復元マシンで、コマンド mysql -uusername -ppassword -S /tmp/mysql.sock dbname tablename | mysql -uusername -ppassowrd -hhost -Pport を実行します。

上記のコマンドを使用すると、ダンプおよびインポート操作を直接完了できます。欠点は、バックアップ ファイルが生成されないことです。

ステップ5:

基本的な DBA の仕事は終了です。この時点で、開発スタッフにリカバリが完了したことを通知し、アプリケーションのテストとデータの正確性の検証を実施する必要があります。すべてが正常であれば、名前を変更したテーブルを削除すれば、回復操作は完了です。

存在する場合はテーブルを削除します tablename_bak;

データベースのリカバリはすべての DBA にとって必須のスキルであり、習得する必要があります。この記事を読んだ受講者がリカバリ操作を簡単に実行できるようになることを願っています。

追伸：この操作は1万年に1回は使用しない方がよいでしょう。

上記は、MySQL 単一テーブルリカバリの手順の詳細な内容です。MySQL 単一テーブルリカバリの詳細については、123WORDPRESS.COM の他の関連記事に注意してください。