0

このクエリをスレーブ マシンで実行しています。

クエリ:

select ID from audit where app='accounts'

出力を説明する

    +----+-------------+-----------------+------+---------------+------+---------+------+-----------+-------------+
| id | select_type | table           | type | possible_keys | key  | key_len | ref  | rows      | Extra       |
+----+-------------+-----------------+------+---------------+------+---------+------+-----------+-------------+
|  1 | SIMPLE      | IAMAccountAudit | ALL  | NULL          | NULL | NULL    | NULL | 155658522 | Using where |
+----+-------------+-----------------+------+---------------+------+---------+------+-----------+-------------+

実行後、私のスレーブ マシンはマスターの背後で実行されていました。

    *************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 182.31.251.94
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: bin.001487
          Read_Master_Log_Pos: 2967065
               Relay_Log_File: 172-relay-bin.004312
                Relay_Log_Pos: 43303861
        Relay_Master_Log_File: bin.001486
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 43303721
              Relay_Log_Space: 55397036
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 365
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1302078

増え続けています。

mysql バックログを回避するにはどうすればよいですか? .

4

1 に答える 1

2

操作するテーブル スキーマがあれば、少しは役に立ちます。ただし、私が見ることができるクエリは、インデックスを使用しておらず、最初のレコードから最後のレコードまでテーブルを 1 つずつ順番に読み取っています。

クエリは約 1 億 5,565 万 8,522 行または 1 億 5,500 万行を調べる必要があるため、サーバーでリソースの枯渇が発生します。クエリには、クエリしている列に適切なインデックスがないため ( key= nullExplain 出力)、行は 1 つずつ発行された読み取りロックを取得しています。

この読み取りが行われている間、MySQL がレプリケーション アクティビティをブロックする可能性があります。つまり、読み取り中の行の更新がブロックされる可能性があります。MySQL は、これらの更新が完了できないため、キューに入れます。この問題は、スレッドなどではなく、サーバーの ACID 準拠が原因です。エンジンなどのテーブル情報がないため、これはせいぜい経験に基づいた推測です。

提案:

  1. テーブルのアプリ列にインデックスを付けて、選択をより高速に実行できるようにします。app 列にインデックスがあると、MySQL は順次検索ではなく、テーブルで B ツリー検索を実行します。より少ないロックを発行してクエリを高速に実行できるため、より高速で軽量になります。欠点は、維持する追加のインデックスがあるため、このテーブルの更新と挿入がわずかに遅れることです。
  2. ナノ秒のリアルタイム レプリケーションが必要でない限り、システムはそのままにしておきます。リアルタイム データの要件がない場合、レプリケーションが遅れても問題ないことに注意してください。レプリケーションの失敗はさらに悪いことです。

これが少し役立つことを願っています。

于 2013-01-29T10:03:09.650 に答える