MySQL で削除されたレコードが有効にならない理由のトラブルシューティング

オンライン MySQL トランザクションの問題の記録

先週の金曜日、大きなテーブルを削除する操作を実行しました。削除プロセス中に小さな問題が発生し、2 時間を無駄に費やしました。ここで一般的なプロセスを記録しました。これ以上前置きせずに、プロセスを見てみましょう。

当時は削除したかったので、まずは削除文の構文をテストし、次のようにして 1 つ削除してみました。

mysql ::>>XXXX_user_loginからmin(id)を選択します。
+---------+
| 最小(id) |
+---------+
| |
+---------+
 セット内の行数 (0.00 秒)

mysql ::>>ID < ; の XXXX_user_login から削除します。
クエリは正常、行は影響を受けました (0.00 秒)

mysql ::>>XXXX_user_loginからmin(id)を選択します。         
+---------+
| 最小(id) |
+---------+
| |
+---------+
 セット内の行数 (0.00 秒)

その後、MySQL クライアントを使用して再度ログインすると、奇妙な問題が見つかりました。

[dba_mysql ~]$ /usr/local/mysql/bin/mysql -udba_admin -p -h127.0.0.1 -P4306
パスワードを入力してください: 
XXXXXXXXXXXXXXXXXXXXXXXX
ヘルプを表示するには、「help;」または「\h」と入力します。現在の入力ステートメントをクリアするには、「\c」と入力します。

mysql ::>>XXXXX_user_loginからmin(id)を選択します。                  
+---------+
| 最小(id) |
+---------+
| |
+---------+
 セット内の行数 (0.00 秒)

つまり、削除されたばかりのレコードが再び戻ってきたことになります。

よく考えてみるとかなり不思議です。間違って削除してしまったのでしょうか？ それとも削除した後、業務側でデータを入れ直したのでしょうか。これは問題ないのでしょうか？ 。 。何度か試してみましたが、結果は同じでした。

この現象は非常に奇妙です。私はこれまで一度も遭遇したことがありません。まずスクリプトをチェックし、削除されたスクリプトが正しいことを確認しました。その後、長時間チェックし、ついにトランザクションの方向から突破口を見つけました。トランザクションが送信されていないことが原因ではないかと疑いました。そこで、現在のトランザクションのパラメータを次のように確認しました。

mysql ::>> '%commit%' のような変数を表示します。   
+--------------------------------+-------+
| 変数名 | 値 |
+--------------------------------+-------+
| 自動コミット | オフ |
| innodb_commit_concurrency | |
| innodb_flush_log_at_trx_commit | |
+--------------------------------+-------+
 セット内の行数 (0.00 秒)

[email protected]:(なし) ::>>
mysql ::>> '%commit%' のようなグローバル変数を表示します。
+--------------------------------+-------+
| 変数名 | 値 |
+--------------------------------+-------+
| 自動コミット | オン |
| innodb_commit_concurrency | |
| innodb_flush_log_at_trx_commit | |
+--------------------------------+-------+
 セット内の行数 (0.00 秒)

これを見ると、基本的に問題は特定できました。現在のセッションの自動コミットがオフに設定されているため、削除すると成功したようです。再起動後、これらのトランザクションはロールバックされているため、削除操作が「無効」になっているようです。

問題が特定されたので、問題の根本原因の調査を開始します。最終的に、次のように構成ファイルで根本原因が見つかりました。

[mysqlダンプ]
素早い
最大許容パケット数 = M

[mysql]
自動再ハッシュなし
最大許容パケット数 = M
プロンプト=mysql--\\u@\\h:\\d \\R:\\m:\\s>>
init-command="interactive_timeout=28800 を設定;wait_timeout=28800 を設定;autocommit=0 を設定;"

設定ファイルの最後の行で、mysql クライアント グループの自動コミット設定が 0 に設定されていました。当然、自動的に送信することはできませんでした。そこで、このパラメータを 1 に変更してスクリプトを再度試してみましたが、問題は依然として存在することがわかりました。 。 。

変更はまだ徹底されていないようです。

MySQL が設定ファイルをロードするためのシーケンスがあることはわかっています。mysql --help|grep my.cnf コマンドを使用してそれを表示できます。確認したところ、/etc/my.cnf の設定も autocommit=0 であるため、現在の設定ファイルのパラメータが上書きされていることがわかりました。最後に、/etc/my.cnf ファイルで autocommit パラメータの内容を変更した後、MySQL サーバーに再接続すると、問題が解決されていることがわかります。

要約すると、次の小さな知識のポイントに注意する必要があります。

1. データを削除できない場合は、まずトランザクション送信パラメータがオフに設定されているかどうかを確認します。

2. show variables と show global variables を使用して、それぞれ現在のセッションとグローバル変数のトランザクション パラメータを表示します。

3. my.cnf ファイルの mysql グループのパラメータは、mysql クライアントの構成を制御するために使用されます。

4. my.cnf ファイルには読み込み順序があります。これを変更する場合は、すべて変更する必要があります。または、my.cnf ファイルが 1 つだけあることを確認します。

上記は、MySQL の削除されたレコードが有効にならない理由のトラブルシューティングの詳細な内容です。MySQL の削除されたレコードが有効にならないことの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。