У меня есть мастер, который имеет 298 файлов ретрансляторов совсем недавно, и теперь работает хорошо 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)

Если у Мастера есть релейные журналы, то он также должен быть Ведомым среди топологии репликации (т. Е. Мастер / Мастер, репликация с последовательным подключением)

Что может заставить журналы реле расти таким образом?

Сломанная репликация

Репликация MySQL прерывается, когда поток IO или поток SQL умирает под этими сценариями:

• СЦЕНАРИЙ № 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 Thread продолжал собирать команды SQL от Master, увеличивая количество журналов ретрансляции

Это СИТУАЦИЯ # 3 , что это проблема. Когда поток SQL умирает из-за ошибки SQL, в MySQL Replication нет встроенного механизма, который инициирует отключение потока ввода-вывода .

РЕКОМЕНДАЦИЯ

Единственный достойный способ контролировать рост релейных логов - это установить на него ограничение

[mysqld]
relay_log_space_limit=4G

Установка relay_log_space_limit устанавливает ограничение 4G.

Когда релейный журнал полностью обработан

• это вращается
• поток SQL начинает работать на следующем журнале ретрансляции
• поток ввода-вывода начинает загружать SQL из мастера с последнего места, откуда он вышел, при условии, что на диске достаточно свободного места

Эпилог

Если Мастер был Рабом, и он больше не требуется, просто отключите его.

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

Если Master является Slave, исправьте ошибку 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.

РЕДАКТИРОВАТЬ: Вы маскировали фактическое имя файла binlog в show master statusвыводе? Я спрашиваю, потому что настройка в my.cnf не совпадает с именем binlog. Если да, то не могли бы вы указать реальное имя файла и результат, о котором show slave statusупоминал Аарон? До сих пор, кроме несоответствия имени для bin-log, в вашем файле my.cnf ничего не выделяется.

Выполните команду RESET SLAVE. Это очистит журналы реле и восстановит новый. Но, он не будет использовать новый. Вы можете проверить, запустив позже команду FLUSH LOGS, сервер не будет создавать второй релейный журнал.