マスタースレーブとして構成された2つのノードで構成されるMariaDB(5.5.41
)クラスターがあります。すべての読み取りと書き込みは同じノードに送信されます。
数週間、いくつかのデッドロック問題を調査してきました。
定期的に、my PHPアプリケーションはMessage: SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction.
を返します
以前はSHOW ENGINE INNODB STATUS;
を実行でき、最後のデッドロックが発生しましたが、何らかの理由で、無関係な構成を少し変更し(innodb_buffer_pool_instances
を1から19に変更)、両方のノードを再起動した後、 SHOW ENGINE INNODB STATUS;
を実行しても、デッドロックは表示されません。
ただし、MySQLクライアントに接続して手動でトランザクションを作成すると、デッドロックが発生する場合、ステータスコマンドdoesがデッドロックを表示します。
innodb_print_all_deadlocks
をONとOFFで遊んでみました。手動でトリガーされたデッドロックを除いて、mysql-error.log
には何も表示されません。
なぜmy PHPアプリケーションが表示しない)によってデッドロックが作成されるのですか?
私はあなたのシステムと与えられた情報へのアクセスの欠如を考えると、私はあなたの質問に直接答えることはできないと思います。ただし、ここでは、私が管理を担当したすべての種類のMySQL派生データベースを適切に処理するために使用したいくつかの素晴らしいツールを示します。
InnoTop: https://github.com/innotop/innotop
Innotop manページの「D」コマンドをチェックしてください:
D: InnoDB Deadlocks
This mode shows the transactions involved in the last InnoDB
deadlock. A second table shows the locks each transaction held and
waited for. A deadlock is caused by a cycle in the waits-for
graph, so there should be two locks held and one waited for unless
the deadlock information is truncated. [...]
「K」コマンドと「L」コマンドも関連する可能性があります。
注:innotopを十分に活用するには、スキーマ情報と設定を変更し、「テスト」データベースを追加して情報を収集する必要がある場合があります。 データベース全体を盲目的に変更する前に、何をしようとしているのかを知るために、全体を読むMAN PAGE(個人的には、innotopの変更に関する追加情報が大好きです発表...)
ロックの問題にはあまり関係がありませんが、それでも非常に便利です。
Perconaツールキット(以前のMAATKIT): https://www.percona。 com/software/database-tools/percona-toolkit
幸運を!
show engine innodb status
が必要なデッドロック情報を提供していないことは非常に不可解です。ただし、mysqladmin debug
を実行してデッドロックを確認できます。これにより、すべてのロックと、この場合show engine innodb status
には表示されないLOCK TABLEロックが記録されます。
これらの問題は時々間違った時に存在し、それは多くの時間を浪費します。私は個人的に Monyog を使用して、これもこれを行うことを監視しています。何も機能しない場合は、試用版を使用してみてください。