MySQLデータが紛失した場合のチェック例

前言
最近、ある友達が突然WeChatで連絡しました。MySQLにデータがなくなったと言いました。間違いなく、DBAにとって一番緊張していることは一つもありません。このニュースを聞いて、私もすぐに問題の調査に入りました。
現場調査
最初にこのニュースを聞いて、私の心の中ももちろんとても緊張しましたが、すぐに自分を落ち着かせて、検査を始めました。
（1）インスタンスの状態は正常ですか？    --確認したところ、実例の状態は正常です。
（2）業務庫はどれですか？まだありますか？削除されますか？    --確認したところ、業務倉庫が存在します。
（3）業務はどの表を訪問しますか？この表は存在しますか？削除されますか？    --業務表の存在が確認されました。
(4)アプリケーションユーザの権限は正常ですか？    --ユーザーがライブラリのすべての権限を持っていることが確認されました。
（5）業務訪問は何の間違いですか？    --確認したところ、業務側はいくつかのページにアクセスしてエラーが発生しました。
（6）ここまで検査したところ、アプリケーションに異常があるかどうかの疑いがある一方、一部の記録がなくなったかどうかの疑いがある。開発側と維持側は同時に検査していますが、こちらは運行維持側に検査する考えです。業務表に主なキーがありますか？業務側アクセスエラーと業務表の対応関係はどうなりますか？該当する記録を探し出せますか？
（7）さらに分析してみると、この業務表にはメインキーがあり、開発側も問い合わせの記録を提供しています。この記録が存在することを確認したところ、誤って削除されていません。開発側はデポジットアプリケーションをチェックしていますが、ログもはっきりと印刷されていません。エラーメッセージがあります。
（8）この場合は、まずその日の夜に何か変更/発表があるかを聞いてみます。    --確認したところ、その夜、いくつかの表のDDLが変更されました。
引き続き検査して発見して、その夜DDL変更はこの業務表の操作に関連していて、変更内容は修正フィールド長で、alter table x x x modify column xxx char（x）に類似しています。問題はここまで来ても考えが出てきます。次からは検査を始めます。modeの設定、クエリに対応する完全行を開発確認に記録し、最終的にDDLの変更によるフィールドの遮断が確認されました。最後にバックアップで回復するしかなく、問題は最終的に解決されました。
判例が復活する
先ほどの検査過程を見てから、多くの子供靴に疑問があると思いますが、なぜフィールドの長さを変更するとデータが遮断されますか？MySQLはデータチェックをしませんか？続いて下を見ましょう。
（1）シーン1

mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k       | c                                                                                                                       | pad                                                         |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
|  1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> alter table sbtest2 modify column pad char(1);
ERROR 1265 (01000): Data truncated for column 'pad' at row 1

mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k       | c                                                                                                                       | pad                                                         |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
|  1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)

（2）シーン2

mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k       | c                                                                                                                       | pad                                                         |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
|  1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> alter table sbtest2 modify column pad char(1);Query OK, 100 rows affected, 100 warnings (0.06 sec)
Records: 100  Duplicates: 0  Warnings: 100

mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
| id | k       | c                                                                                                                       | pad  |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
|  1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 6    |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
1 row in set (0.00 sec)

シーン1は私達の予想に合っています。直接にエラーを報告します。「データが遮断されました。」シーン2は実行に成功し、「データ部分のロス」を引き起こします。では、MySQLはデータチェックを行っていませんか？実はMySQLはデータをチェックしています。ただシーン2にあります。modeの配置に問題があります。STRICT_は設置されていません。TRANS_TABLESは、MySQLがこの操作の実行を停止していないため、「データがなくなった」という惨事を引き起こしました。
締め括りをつける
これで、「データ紛失」の惨事も一段落する。モデルはSTRICTを設置していません。TRANS_TABLES;このケースも注意してくれています。modeは非常に重要な構成です。勝手に設定したり、修正したりしてはいけません。sqlについてmodeのもっと多い内容、次の文章は引き続きみんなに分かち合うことができます。
以上はMySQLデータが紛失した場合の詳しい内容です。MySQLデータの紛失についての調査資料は他の関連記事に注目してください。