私には、今日のところ最近298のリレーbinファイルがあり、298日前まで遡るマスターがあります。

.cnfにリレーログ定義がありません

そして

mysql> show variables like '%relay%';
+---------------------------------+----------------+
| Variable_name                   | Value          |
+---------------------------------+----------------+
| innodb_overwrite_relay_log_info | OFF            |
| max_relay_log_size              | 0              |
| relay_log                       |                |
| relay_log_index                 |                |
| relay_log_info_file             | relay-log.info |
| relay_log_purge                 | ON             |
| relay_log_space_limit           | 0              |
+---------------------------------+----------------+

スレーブをリセットすると、それらはクリアされますが、その後、再生が開始されます。

これを引き起こしているものは何ですか？それを止める方法は？

リクエストの編集

CNFの一般的な批評は歓迎されますが、OPトピックを念頭に置いておいてください。

---- cnf request

[mysqld]
character_set_server = utf8

max_connections=200
max_user_connections=160
max_connect_errors=10000

userstat_running = 1

log_warnings
slow_query_log=1
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2


innodb_file_per_table

innodb_open_files=2048

innodb_additional_mem_pool_size=1M

innodb_buffer_pool_size=512M

innodb_log_buffer_size=1M

innodb_log_file_size=128M

innodb_autoextend_increment=16


innodb_flush_method=O_DIRECT


datadir=/var/lib/mysql/


tmpdir=/var/lib/mysql_ramdisk


server-id=2

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

key_buffer_size = 800M

preload_buffer_size = 256K

max_allowed_packet = 8M
table_cache = 512
sort_buffer_size = 8M
join_buffer_size = 8M

read_buffer_size = 2M
read_rnd_buffer_size = 2M
thread_cache_size = 32
query_cache_size = 32M
query_cache_limit = 16M


myisam_sort_buffer_size = 2000M


tmp_table_size = 64M
max_heap_table_size = 64M

---- now for the cli requests

mysql> show slave status\G
Empty set (0.00 sec)

mysql> show master status;
+---------------------+----------+--------------+------------------+
| File                | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+--------------+------------------+
| awesome-bin.xxxxxxx | yyyyyyyy |              |                  |
+---------------------+----------+--------------+------------------+
1 row in set (0.00 sec)



---- version


mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.1.47-rel11.1-log |
+--------------------+
1 row in set (0.00 sec)

マスターにリレーログがある場合、マスターは一部のレプリケーショントポロジ（マスター/マスター、デイジーチェーンレプリケーションなど）の最中のスレーブでもある必要があります。

リレーログがこのように大きくなる原因は何ですか？

壊れた複製

これらのシナリオでIOスレッドまたはSQLスレッドが停止すると、MySQLレプリケーションが壊れます。

• シナリオ＃1：IOスレッドとSQLスレッドがオフの場合、次のいずれかが発生しました
  • MySQLはskip-slave-start有効にして開始されました
  • 誰か/何かが走ったSTOP SLAVE;
• シナリオ＃2：IOスレッドが停止したとき
  • 何もリレーログを積み上げることができません
  • SQLスレッドは、リレーログ内のすべてのSQLコマンドを処理するか、SQLエラーが発生するまで処理します
• シナリオ＃3：SQLスレッドが停止したとき
  • SQLコマンドの処理中にSQLエラーが発生しました
  • 実行SHOW SLAVE STATUS\GするLast_Errnoと、Last Error
  • IOスレッドがマスターからSQLコマンドを収集し続け、リレーログが増大する

問題は、状況＃3です。SQLエラーが原因でSQLスレッドが停止した場合、MySQLレプリケーションには、IOスレッドを切断するトリガーとなる組み込みのメカニズムはありません。

勧告

リレーログの増加を制御する適切な方法は、制限を設定することです。

[mysqld]
relay_log_space_limit=4G

relay_log_space_limitを設定すると、4Gの上限が設定されます。

リレーログが完全に処理されたとき

• 回転します
• SQLスレッドは次のリレーログの処理を開始します
• I / Oスレッドは、ディスク上に十分な空き容量がある限り、マスターからのSQLのロードを、最後の場所から開始します。

エピローグ

マスターがスレーブになっていて、それが不要である場合は、単純に無効にします。

mysql -e"STOP SLAVE; CHANGE MASTER TO MASTER_HOST='';"
rm -f /var/lib/mysql/master.info

マスターがスレーブの場合、SQLエラーを修正します。

SQLエラーが邪魔な場合は、これをお勧めします。

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE SQL_THREAD;

その後、SHOW SLAVE STATUS\G毎分実行して、リレーログが処理されてローテーションされるかどうかを確認します。

my.cnfを確認しないと、この質問に答えることはできませんが、SHOW SLAVE STATUS \ Gの出力を投稿することをお勧めします-スレーブが実際に信じられないほどはるかに遅れている可能性はありますか？それはリレーログを維持します。SQLスレーブスレッドは実行されていますか？

my.cnfファイルが正しく構成されておらず、マスターバイナリログの名前がリレーログである可能性がありますか？

または、マスターのレプリケーション設定がmy.cnfファイルにハードコードされている場合があります。これは、MySQLインスタンスの再起動時に取得されます。

編集：show master status出力で 実際のbinlogファイル名をマスクしましたか？my.cnfの設定がbinlog名と一致しないため、私は尋ねています。もしそうなら、実際のファイル名と、show slave statusアーロンが述べたような出力を提供できますか？これまでのところ、bin-logの名前の不一致を除いて、my.cnfファイルでは何も目立ちません。

RESET SLAVEコマンドを実行します。リレーログを消去し、新しいログを再生成します。ただし、新しいものは使用しません。後でFLUSH LOGSコマンドを実行して確認できます。サーバーは2番目のリレーログを作成しません。