2

非常によく似たInnoDBデータベースがたくさんある大量のdbサーバーがあります。私がよく実行するクエリは、小さなテーブルの1つの行のタイムスタンプを更新するだけです。ほとんどの場合、これには1〜2ミリ秒かかります。場合によっては、夜間、おそらくバックアップとmaatkitレプリケーションツールの実行中に、これらのクエリの1つ以上が数分間「更新中」と表示されることがあります。この間、maatkitクエリを含む他のクエリは正常に進行しているようであり、他のクエリは実行されていないようです。私はこれを説明したり修正したりすることができませんでした。

16ギガのRAMとストレージ用のRAIDドライブを備えた4ウェイXeonのペアでmysql4.1.22とgentoo2.6.21を使用しています。レプリケーションは適切に行われ、maatkitで正常に動作しており、毎晩レプリケーションを確認しています。InnoDBはほとんどのRAMを使用しており、CPUは通常70〜80％アイドル状態です。問題のテーブルには、それぞれ約200バイトの約100行があります。WHERE句のインデックスを使用した場合と使用しない場合で、認識できる変更はありません。異常なログメッセージは見つかりませんでした（チェックされたシステムメッセージとmysqlエラー）。

他の誰かがこれを聞いたことがありますか？このようなことを解決しましたか？調査する方法のアイデアはありますか？

4

3 に答える 3

1

DML操作を行うときInnoDBは、行とインデックスのギャップにロックをかけます。

問題は、影響を受ける行だけでなく、調べたすべての行をロックすることです。

たとえば、このクエリを実行する場合：

UPDATE  mytable
SET     value = 10
WHERE   col1 = 1
        AND col2 = 2

、ロックはクエリに使用されるインデックスによって異なります。

  • インデックスcol1, col2が使用された場合、影響を受ける行のみがロックされます

  • インデックスcolが使用された場合、のすべての行col1 = 1がロックされます

  • インデックスcol2が使用された場合、のすべての行col2 = 2がロックされます

  • インデックスが使用されていない場合、すべての行とインデックスギャップがロックされます（列の場合もロックされるようにPRIMARY KEY）。INSERTAUTO_INCREMENT

さらに悪いことに、EXPLAINinは操作でMySQLは機能しないDMLため、オプティマイザーは最適と見なす場合に任意のインデックスを選択できるため、使用されたインデックスを推測する必要があります。

したがって、レプリケーションツールと更新プログラムが同時にレコードをロックするためである可能性があります（そして、ご覧のとおり、WHERE条件が重複していなくてもこれが発生する可能性があります）。

于 2010-02-12T15:27:11.630 に答える
0

回答で提供された情報の一部を使用して、調査を続け、サーバー上で不穏な動作を見つけました。任意のデータベースの任意のテーブルに対する単純な「チェックテーブル」により、単純な更新クエリが他のデータベースや他のテーブルをロックしていました。MySQL v5.1では再現できませんでしたが、なぜこれが発生するのかわかりません。データベースサーバーをアップグレードする予定です。

maatkitのmk-table-checksumは「チェックテーブル」を実行するとは思いませんが、同様の効果があります。このスクリプトをオフにすると、問題は大幅に減少しましたが、このスクリプトなしでは生きていけないと考えています。

これを私の質問への答えとしてマークします。助けてくれてありがとう。

于 2010-02-26T15:02:02.450 に答える
0

このクエリがハングしているときにサーバーにアクセスできる場合は、「showinnodbstatus」を実行してみてください。そこから取得するデータの混乱の一部は、InnoDBテーブル上のすべてのアクティブな接続/クエリのステータスです。別のトランザクションが原因でクエリがハングしている場合は、そこに表示されます。ここにロックデータのサンプルがあります。

同様に、あなたはそれがdurintバックアップで起こるようだと言います。そのためにmysqldumpを使用していますか？これにより、ダンプがアクティブな間はテーブルがロックされ、ダンプされたデータの一貫性が保たれます。

于 2010-02-12T19:22:32.720 に答える