通过Mysql-bin日志恢复还原数据
提取出来后,里面就是所有对terminfo的sql语句了,把这些数据导入到测试库terminfo0730表中
事情是这样的:由于个人粗心,在7月30号那天协助其它部门批量更新一些数据,谁知道全局更新了,而这个问题竟然在9月26号才发现告知我。他们要求把更新有误的数据恢复到7月30号之前状态,并且7月30号到9月26号这段时间所做的增删改的操作也要更新进去。由于之前没啥经验,心里也没底,但是没办法,自己做错事自己承担。
做法思路:把备份的数据导到测试库里面去,然后把7月30号到9月26号之间的binlog日志提取出对这个表进行操作的sql语句,然后再导进去。
苦逼的还原过程开始了.........
1.幸好本人养成了个好习惯,无论改动的大小我都会先备份一份数据
-rw-r--r-- 1 root root 2473664 07-30 09:38 terminfo-bak0730.sql
找到了,果然是7月30号早上09点38分左右备份的,幸好有备份啊,要不然就悲催了.......先把备份的导到测试数据库上,表名改为terminfo0730,然后再把当前生产的数据导到,表名改为terminfo0926,这样的做法是在还原数据后匹配一下数据有没有对得上。
+----------------+
2.最重要的一步来了,,就是提取binlog日志。因为7月30号备份的,所以要找7月30号之后到9月26号的binlog。
利用mysqlbinlog命令先进行第一轮的sql语句提取
#mysqlbinlog --no-defaults --database=ecard --start-datetime='2012-07-30 09:38:00' mysql-bin.000086 > log86.txt # 这里要设置起始时间
#mysqlbinlog --no-defaults --database=ecard mysql-bin.000087 > log87.txt
#mysqlbinlog --no-defaults --database=ecard mysql-bin.000088 > log88.txt
#mysqlbinlog --no-defaults --database=ecard mysql-bin.000089 > log89.txt
#mysqlbinlog --no-defaults --database=ecard mysql-bin.000090 > log90.txt
#ls -l
提取出来后是全部的sql语句,而我需要的是只对terminfo操作的sql语句,所以要进行第二轮提取
#grep terminfo log86.txt > log86-terminfo.txt #依次grep出来
提取出来后,里面就是所有对terminfo的sql语句了,把这些数据导入到测试库terminfo0730表中
mysql > source log86-terminfo.txt; #依次source进去,务必要注意顺序问题!!!
导进去之后再比较一下terminfo0730和terminfo0926表的数据数量有没有一样,然后再叫部门同事验证一下数据正确性。
到此,数据成功恢复还原。一次难忘的经历啊,也同时告诫自己,细心细心再细心!!

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











1. Binlog Binlog は、データベースによって実行された書き込み操作 (クエリを除く) 情報を記録し、バイナリ形式でディスクに保存するために使用されます。 binlog は mysql の論理ログであり、サーバー層によって記録されます。任意のストレージ エンジンを使用する Mysql データベースは binlog ログを記録します。論理ログ: 単純に SQL ステートメントとして理解できます。物理ログ: MySQL のデータはデータ ページに保存され、物理ログはデータ ページの変更を記録します。ここにコード部分を挿入すると、Input を追加することでバイナリログが書き込まれます。 max_binlog_size パラメーターを使用して、各 binlog ファイルのサイズを設定できます。ファイル サイズが指定された値に達すると、

1. Binlog ログの概要 Binlog は、Binarylog、つまりバイナリ ログの略です。 Binlog には、永続化中のランダム IO からシーケンシャル IO への変換、マスター/スレーブ レプリケーション、およびデータ リカバリという 3 つの主な機能があります。この記事では、マスター/スレーブ レプリケーションに関連する問題に焦点を当てます。 Binlog ログは、インデックス ファイルと多数のログ ファイルで構成されます。各ログ ファイルは、マジック ナンバーとイベントで構成されます。各ログ ファイルは、回転タイプのイベントで終わります。各イベントは、イベント ヘッダーとイベント本体の 2 つの部分に分割できます。イベント ヘッダーの構造は次のとおりです。イベント本体の構造には、固定サイズと可変サイズの 2 つの部分が含まれます。 Binlog ログの形式については簡単に理解できるので、興味のある学生はさらに深く理解することができます。

MySQL には、REDO ログ (redolog)、ロールバック ログ (undolog)、バイナリ ログ (binlog)、エラー ログ (errorlog)、スロー クエリ ログ (slowquerylog)、一般的なクエリ ログ (generallog) の 6 種類のログ ファイルがあります。 )、リレーログ (relaylog)。 1.リドログとは何ですか? Redolog (REDO ログ ファイルとも呼ばれます) は、トランザクション操作の変更を記録するために使用されます。データ変更後の値が記録されます。トランザクションが送信されたかどうかに関係なく記録されます。 Redolog ファイルは、データベースの停電やインなど、インスタンスやメディアに障害が発生した場合 (メディア障害) に役立ちます。

1. 問題の原因 パフォーマンスの問題を分析する場合、低速クエリとバイナリログ低速トランザクションが一般的に使用される方法です。最近、遅いクエリを分析していたところ、低速なコミット ステートメントが多数含まれていることがわかりましたが、binlog の遅いトランザクションを分析する際にマッチングを完了できませんでした。たとえば、この期間中にコミット ステートメントが 1,000 件ある場合でも、遅いトランザクションは 100 件しかない可能性があります。これは大きすぎる差ですが、なぜこの現象が発生するのでしょうか。 2. 遅いトランザクションのそれぞれの判定方法は、通常、明示的に送信 (挿入) されたトランザクションの場合、次のとおりです。 GTID_LOG_EVENT および XID_EVENT は、コマンド「COMMIT」が開始された時刻です。

MySQL バイナリ ログ (binlog) については、バイナリ ログ (binlog) が非常に重要であること、特にポイントツーポイントの災害復旧が必要な場合にバックアップする必要があることは誰もが知っています。バイナリ ログ (binlog) のバックアップについては、最初にフラッシュログ方式に基づいて binlog を切り替えてから、マウントされた NAS ストレージなど、リモート サーバーまたはローカル サーバー上の他のストレージにコピーして圧縮することができます。 MySQL バイナリ ログ (binlog) のローカル バックアップまたはリモート バックアップを実装します。最後に、MySQL バイナリ ログ (binlog

1.kingbusの紹介 1.1kingbusとは何ですか? Kingbus は、raft の強力な整合性プロトコルに基づいた分散 MySQL バイログ ストレージ システムです。 MySQLSlave として機能し、実際のマスターからバイナリログを同期し、分散クラスターに保存できます。同時に、クラスター内のバイナリログを他のスレーブに同期する MySQLMaster としても機能します。 kingbus には次の機能があります。MySQL レプリケーション プロトコルと互換性があり、Gtid を介してマスター上のバイナリ ログを同期し、スレーブが Gtid を介して kingbus からバイナリ ログを取得することをサポートします。

MySQLbinlog/redolog/undolog の違いは何ですか? InnoDB のロック メカニズムについて話したい場合、必然的に MySQL ログ システム、binlog、redolog、undolog などが関係します。友人がまとめたこれら 3 つのログは悪くないと見たので、すぐに持ってきました。パートナーと共有してください。ログは MySQL データベースの重要な部分であり、データベースの操作中のさまざまなステータス情報を記録します。 MySQL ログには、主にエラー ログ、クエリ ログ、スロー クエリ ログ、トランザクション ログ、バイナリ ログが含まれます。開発者として注目する必要があるのは、バイナリ ログ (binlog) とトランザクション ログ (redolog と und を含む) です。

はじめに 開発中は、mysql の binlog ログ ファイルを監視してデータ テーブルを監視する必要がありますが、mysql は Docker コンテナにデプロイされるため、データ量の問題も解決する必要があります 1. データを通じて mysql イメージを開きますvolume dockerrun- p3307:3306--namemyMysql-v/usr/docker/mysql/data:/var/lib/mysql-eMYSQL_ROOT_PASSWORD=123456-dmysql:5.7.25 注: 事前にホスト ディレクトリにファイルを作成する必要がありますmysql データセットを保存するために、ここで作成したディレクトリは /u です。
