если был skip_counter то отдельные ключи могут быть не те, но само оно не может пролететь, значит это ожидаемо

везет )

если был skip_counter то отдельные ключи могут быть не те, но само оно не может пролететь, значит это ожидаемо

за это надо сразу напалмом

за скип каунтер

может у вас с железом беда?

нет

за скип каунтер

иногда норм, при анализе Last_IO_Errno и осознания что скипаем, если это битрикс и там на какой-то хер логи всякие, то скипать смело. Там же нет синхронизации, только редамп

мы так не делаем

ламеры ))

так, вопрос в другом

бывают разные ситуации, когда только skip counter и помогает.

бывают разные ситуации, когда только skip counter и помогает.

что значит только?

дамп-рестор и стоп слейв

и чендж мастер ту

и старт слейв

скипы до хорошего не доведут

прикол весь в том, что (насколько мне известно) не существует способа сказать мускулу на слейве "ничего не писать, принимать только запросы на чтение". Мускул - не постгрес. Криво написанное приложение может сделать запрос, который внесёт какое-нибудь изменение в слейв. А потом с мастера прилетит строчка и возникнет конфликт.

прикол весь в том, что (насколько мне известно) не существует способа сказать мускулу на слейве "ничего не писать, принимать только запросы на чтение". Мускул - не постгрес. Криво написанное приложение может сделать запрос, который внесёт какое-нибудь изменение в слейв. А потом с мастера прилетит строчка и возникнет конфликт.

прослойка в виде maxscale поможет на "только чтение"

костыли.

я говорю лишь о том, что

бывают разные ситуации, когда только skip counter и помогает.

некоторые запросы также могут выполняться с разным результатом на мастере и слейве. Простой пример - удаление с лимитом может удалить разные строки на мастере и слейве вообще запросто.

т.е. делаем запрос "delete ... limit XXX" на мастере и получаем рассинхрон. А потом конфликт.

некоторые запросы также могут выполняться с разным результатом на мастере и слейве. Простой пример - удаление с лимитом может удалить разные строки на мастере и слейве вообще запросто.

слейв должен быть ридонли для приложений

если вы в слейве удаляете - сами себе буратины

я привёл пример ситуации, когда запрос, выполненный НА МАСТЕРЕ, приводит к разным состояниям мастера и слейва.

так не бывает

такое может быть только в одном случае - отключить запись в бинлог

да легко. У меня заббикс работает с мускулом, который реплицируется на слейв для бэкапа и горячего резерва. Так я его мониторю на предмет различий между мастером и слейвом раз в неделю. И почти постоянно есть разница в таблицах history из-за того, что housekeeper выполняет именно удаление с лимитом.

да легко. У меня заббикс работает с мускулом, который реплицируется на слейв для бэкапа и горячего резерва. Так я его мониторю на предмет различий между мастером и слейвом раз в неделю. И почти постоянно есть разница в таблицах history из-за того, что housekeeper выполняет именно удаление с лимитом.

и что?

вы вероятно сильно привыкли к постгресу? в мускульном бинлоге пишутся запросы, а не изменения файлов базы.

слейв тупо получает инфу из бинлога

и что?

да так, ничего. Просто так БЫВАЕТ. И с этим надо считаться.

не бывает

что-то не то

иначе был бы конец света

есть мастер. от мастера мы знаем только имя бинлога и позицию

и есть слейв

который файл этот и читает

все

просто если происходит удаление с лимитом, то надо избегать ситуаций, когда с оставшимися данными происходят какие-то ещё операции.

какая разница?

все идет в бинлог

блджад.

и у нас иннодб

блджад кхйуй

мы на разных языках общаемся, вероятно.

я на русском

все изменения мастера реплицируются на слейв

тчк

в бинлоге пишутся запросы. Не изменения файлов, а запросы. С мастера через бинлог прилетает запрос, который слейв выполняет параллельно с мастером. Результат выполнения запроса на мастере и слейве может быть разным.

будут разные из-за временного лага

когда лаг уходит - все ок

вы сильно привыкли к постгресу.

в нём - да, всё так.

в нём слейв вообще не выполняет запросы мастера. Он получает изменения бинарных данных файлов.

в мускуле тоже так

https://dev.mysql.com/doc/refman/5.7/en/replication-formats.html

нене

пока рано карты из рукава доставать

погуглите deterministic function в mysql.

пока не пойму что хотят доказать

прикол весь в том, что (насколько мне известно) не существует способа сказать мускулу на слейве "ничего не писать, принимать только запросы на чтение". Мускул - не постгрес. Криво написанное приложение может сделать запрос, который внесёт какое-нибудь изменение в слейв. А потом с мастера прилетит строчка и возникнет конфликт.

есть engine=blackhole, или я неправильно понимаю?

в нём слейв вообще не выполняет запросы мастера. Он получает изменения бинарных данных файлов.

https://dev.mysql.com/doc/refman/5.7/en/replication-features-limit.html

так не бывает

увы, бывает. Вариант тогда - replication=row

еще есть GTID

еще бывает с автоинкрементом косяк, разные номера строк

ERROR: S client not available

да мало ли чего бывает такого, от чего помогает только skip counter. С чего собственно разговор и начался.)

при row-based данных много, зато оно синхронно

по задумке, оптимальный должен быть mixed

что и прописано в документации)

да, об этом я тоже в курсе, уже даже забыть успел. Потому что в сложных проектах уже давно с постгресом работаю, с которым проблем таких исчезающе мало. Что в любом случае не отменяет факта - вполне возможны ситуации, когда запрос на мастере приводит к рассинхрону данных между мастером и слейвом.

скип - когда есть понимание что поехала инфа но репликация важнее

хотя бы до спада нагрузки пережить

восстанавливаем реплику, потом синхронизируем данные перкона тулзами и готово.

безопасно и без даунтаймов

мускуль завез синхронизацию? О_О

я там только дикие костылищи видел

мускуль завез синхронизацию? О_О

перкона тулкит завезла

с вычислениями мд5?

оно и было

Итак, повторю вопрос (скрипты уже глянул, ничего интересного)

хочу сделать триггер на show slave status для мускуля, с грепом Seconds_Behind_Master Могу ли я сделать сбор этого времени и при этом триггер на значение NULL? Или надо тогда вместо NULL отдать что-то типа -1 и уже реагировать на такие числа? И хорошо бы учесть ещё, если вдруг репликация не поднята, то есть греп будет просто пустым. Надо что-то типа -2 или можно так оставить и потом проверять на ""?

хочу сделать триггер на show slave status для мускуля, с грепом Seconds_Behind_Master Могу ли я сделать сбор этого времени и при этом триггер на значение NULL? Или надо тогда вместо NULL отдать что-то типа -1 и уже реагировать на такие числа? И хорошо бы учесть ещё, если вдруг репликация не поднята, то есть греп будет просто пустым. Надо что-то типа -2 или можно так оставить и потом проверять на ""?

значение NULL в численный тип не запишешь. Можно сделать триггер на nodata (который сработает, когда прилетит NULL и элемент станет not supported), но это костыль.

именно поэтому лучше мониторить ошибку отдельно. Особенно если это всё равно в планах.

значение NULL в численный тип не запишешь. Можно сделать триггер на nodata (который сработает, когда прилетит NULL и элемент станет not supported), но это костыль.

то есть выставив -1, получаем невозможное в нормальной работе значение, на которое можно триггерить.

я решал ту же задачу когда-то. Можно, но грязный это способ и не очевидный. Влечёт сложности в будущей поддержке.

к тому же, надо тогда и Last_SQL_Errno ловить - если что-то не так в SQL части, в IO будет всё ок а в seconds - null

так чтобы предельно чисто и понятно - +1 элемент на ошибку. Особенно если его всё равно планируется мониторить.

аа. Вот чо вспомнил.

в errno 0, а в секундах null - возможно только в случае, когда слейв остановлен.

у меня это как раз один из кейсов, которые мне надо было предусмотреть - чтобы заббикс не триггерил алерт, когда слейв остановлен для снятия бэкапа.

в errno 0, а в секундах null - возможно только в случае, когда слейв остановлен.

так что доп проверка.

так если слейв вручную остановлен, это как минимум санкционированно.

ну короче, вот теперь я точно всё вспомнил. :) Если хочется мониторить в т.ч. состояние, когда слейв остановлен, но не запущен (скрипт сфейлился, админ забыл запустить, итп) - тогда да, надо. Я в моём случае мониторю nodata на секунды, триггер срабатывает в случае отсутствия данных более 3 часов.

но это уже такая капитальная "защита от дурака", на самом деле. Но нужная на всякий случай, да. Впрочем, у меня этот триггер никогда не срабатывал.)

Добрый вечер ребята. Есть такое проблема все проблемы и решении высвечивается по 2 раза.