У меня были интересные проблемы с Maria DB.
1-й У меня есть max_connections в конфигурации в разделе [mysqld], но значение всегда 214 (по умолчанию) после перезапуска. Итак, проблема в том, что я не могу определить значение в конфигурации (версия сервера 5.5.32-MariaDB-log)
2-й напрямую связан с репликацией mysql: Итак, у меня есть простой мастер настройки репликации - подчиненный мастер mysql 5.1.62-0ubuntu0.11.10.1-log slave 5.5.32-MariaDB-log
поэтому у меня возникла проблема во второй раз, и я не могу понять, как отладить эту проблему или что может быть вызвано
Exec_Master_Log_Pos: 101702714
Relay_Log_Space: 1591329
поэтому после того, как я побежал, покажите статус подчиненного; он показывает мне эти выше значения и 0 позади ведущего, скажем, через 2–3 минуты я снова запускал отображение состояния ведомого; и у меня были все те же значения и 0 позади. Я проверил, что два других ведомых устройства работают нормально. Также нет проблем с идентификатором сервера, каждый сервер имеет другой идентификатор. Так есть идеи, ребята?
Спасибо
Хорошо, я обнаружил проблему с первым вопросом, есть ответ: возникла проблема с ограничением открытия файлов, поэтому для решения этой проблемы я добавил эти значения в my.cnf
max-connections = 950
open-files-limit = 65535
Спасибо
Хорошо, я тоже решил вторую проблему. В целом возникла проблема с потоком ввода-вывода для репликации. Из-за проблем с сетью или задержки в сети.
Вкратце, все выглядит так: ведомое устройство подключается к ведущему, а ведущее устройство отправляет события бинарных журналов ведомому. и поскольку эти данные выталкиваются из главного устройства, а не извлекаются подчиненным устройством, существует вероятность того, что канал репликации может быть нарушен. Таким образом, ведомое устройство не заметит, пока не произойдет slave_net_timeout (по умолчанию 3600). Проблема началась около 21:50, исправлена самостоятельно около 22:50. (см. график двоичного / релейного журнала). В моем случае. Также, когда я запустил список процессов и поискал те процессы, которые отвечают за репликацию (например, пользователь "repl"), вы найдете
290659 repl hostname:56896 NULL Binlog Dump 1215563 Has sent all binlog to slave; waiting for binlog to be updated NULL
где этот тип информации означает, что система исправна, в нездоровой системе мы должны видеть
"Writing to net NULL"
и я видел эти вещи. Также я обнаружил, что примерно в то время у нас было "close_waits" в Master DB, что может указывать на то, что канал для репликации нарушен. В mysql есть параметр slave_compressed_protocol (по умолчанию выключен).
Поэтому после изменения этих значений по умолчанию на 120 и включения сжатия я не вижу этих проблем, если нет более серьезных проблем с сетью.
Путем изменения
master-retry-count=0
ваш раб будет продолжать попытки восстановить соединение с Мастером до успеха