web-dev-qa-db-ja.com

MySQLマスターマスターレプリケーションは古いログを自動フラッシュします

私はmysql-5.1.41マスターマスターセットアップをubuntuマシンで実行しており、以下はマスターの設定です。

skip-Host-cache
skip-name-resolve
event_scheduler = ON
max_connections = 500
max_connect_errors = 1000

server-id = 10
replicate-same-server-id = 0
auto-increment-increment = 10
auto-increment-offset = 1

master-Host = 192.168.1.106
master-user = repli
master-password = secret
master-connect-retry = 60

binlog-format = MIXED
binlog-ignore-db = information_schema
binlog-ignore-db = lb1

log-bin = /var/log/mysql/mysql-bin
log-bin-index = /var/log/mysql/bin-log.index

log-slave-updates
report-Host = 192.168.1.105
replicate-ignore-db = information_schema
replicate-ignore-db = lb2

relay-log = /var/log/mysql/relay.log
relay-log-index = /var/log/mysql/relay-log.index

ログファイルは毎日増加しているようです。同期に損傷を与えないまともな値で古い不要なログを自動的に削除/フラッシュするために、上記の構成に含める必要があるパラメーターを誰かが知っていますか？.

mysqlreplicationlogsmysql-5.1
3
user53864

7日以上経過したログをローテーションアウトするには、これをmy.cnfに追加します

[mysqld]
expire-logs-days=7

次に、mysqlを再起動します。

これを手動で実行するには、次のコマンドを実行します。

mysql> PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 7 DAY) + INTERVAL 0 SECOND;

これにより、バイナリログは7日前の真夜中まで消去されます。

警告!!!

バイナリログをローテーションするためのmysqldの内部機能を妨害するため、OSレベルからバイナリログを消去しないでください。

PDATE 2012-01-24 13:20 EDT

レプリケーションが使用しているバイナリログをパージしないようにしてください。

バイナリログを手動で安全に消去する方法の例を次に示します...

マスター-マスターセットアップM1およびM2の場合

M2に移動し、これを実行します。

mysql> SHOW SLAVE STATUS\G

バイナリログ名を示す2行が表示されます

  • Master_Log_File
  • Relay_Master_Log_File

Master_Log_Fileは、M2で最後に読み取られたM1の現在のバイナリログを表します。

Relay_Master_Log_Fileは、M2で最後に実行されたM1の現在のバイナリログを表します。

M2がこれを持っているとしましょう：

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.176.205
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000131
          Read_Master_Log_Pos: 570079419
               Relay_Log_File: relay-bin.003496
                Relay_Log_Pos: 251
        Relay_Master_Log_File: mysql-bin.000131
             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: 570079419
              Relay_Log_Space: 545
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

mysql>

M2では、Relay_Master_Log_Fileはmysql-bin.000131と言います。 M1では、次のように実行できます。

mysql> PURGE BINARY LOGS TO 'mysql-bin.000131';

Master_Log_FileとRelay_Master_Log_Fileは同じなので、Master_Log_Fileを使用しないのはなぜですか？

理由＃1：スレーブでのSQLエラー

SQLエラーがSQLスレッドのM2で発生すると、レプリケーションはリレーログからのSQLの処理を停止します。 IOスレッドは、M1から新しいSQLエントリをダウンロードし続け、M2のリレーログに追加し続けます。

理由2：スレーブで長時間実行されるSQLクエリ

テーブルのすべての行を更新するUPDATEなどのクエリが発生すると、5分かかります。これらの5分間、the IOスレッドはM1から新しいSQLエントリをダウンロードし、M2のリレーログに追加し続けます。

両方の理由により、Relay_Master_Log_FileとMaster_Log_Fileが異なる場合があります。その場合は、常にRelay_Master_Log_Fileを使用してください。これに照らして、別の理由があります：

理由＃3：スレーブまたはマスターのログ破損

悪いネットワーク伝送が破損したリレーログを生成することはまれです。 SHOW SLAVE STATUS\Gを実行すると、バイナリログが破損している可能性があることを説明するエラーメッセージが表示されます。リレーログからfirsdtを開始する必要があります。

それらを消去して新しいセットで開始するには、SHOW SLAVE STATUS\Gを実行し、Relay_Master_Log_File（RMLF）、Exec_Master_Log_Pos（EMLP）を取得して、M2で実行します

STOP SLAVE;
CHANGE MASTER TO master_log_file='RMLF',master_log_pos=EMLP;
START SLAVE;

CHANGE MASTER TOコマンドは、すべてのリレーログを消去し、最初からダウンロードを開始します。

START SLAVE;を実行した後、破損したエラーログメッセージが再度表示される場合は、ネットワーク転送に問題はありません。結局のところ、M1のバイナリログが破損している可能性があります。

M1に移動して、疑わしいログのコピーを作成し、コピーしたバイナリログに対してmysqlbinlogを実行して、テキストファイルにリダイレクトする必要があります。テキストファイルを読み取ります。テキストファイルに意味不明な文字や識別できない文字が含まれている場合は、スレーブの完全同期を実行する必要があります。

8
RolandoMySQLDBA