У меня есть экземпляр сервера MySQL, настроенный с включенным двоичным ведением журнала. Я не занимаюсь репликацией, но двоичные журналы являются частью нашего плана восстановления - чтобы иметь возможность воспроизвести все транзакции с момента последнего полного резервного копирования.
Не так давно в системе, которая работала в течение нескольких недель, было замечено, что журнал ошибок MySQL вырос до чрезмерного размера более 5 ГБ. Заглянув в журнал, почти каждая написанная в нем строка содержала предупреждение о «небезопасном операторе, записанном в двоичный журнал».
Сейчас я не контролирую приложение, использующее базу данных, поэтому я не могу попытаться сделать эти утверждения «безопасными». Итак, в качестве «исправления» я настроил binlog_format к СМЕШАННЫЙ, скорее, чем ЗАЯВЛЕНИЕ. Это говорит MySQL использовать ЗАЯВЛЕНИЕ ведение журнала там, где это возможно, но вернитесь к СТРОКА ведение журнала с небезопасными заявлениями. Это позволило сохранить размер журнала ошибок на приемлемом уровне.
ОДНАКО теперь бинарные логи растут много быстрее, чем раньше (я видел 3 ГБ файлов журнала всего за несколько часов сегодня), предположительно потому, что теперь система записывает в журнал для каждой затронутой строки (для "небезопасных" операторов), а для операторов, которые влияют на большое количество строк, вы получаете изображение.
Итак, я оказываюсь между камнем и наковальней. Если я использую ЗАЯВЛЕНИЕ формат, двоичные журналы управляемы, но я получаю безумное количество предупреждений в журнале ошибок. Если я использую СМЕШАННЫЙ формат, журнал ошибок в порядке, но двоичные журналы растут достаточно быстро, чтобы заполнить раздел даже за один день.
Это подводит меня к моему вопросу: каковы именно последствия этих «небезопасных» заявлений? Как я уже сказал, у меня нет репликации, поэтому мне не нужно беспокоиться о том, что один сервер точно такой же, как другой. Мне просто нужно убедиться, что в случае, если нам потребуется восстановить из резервной копии, все данные будут там. Приведет ли запись в журнал «небезопасных» операторов к потере данных или просто возникнет ситуация, когда определенные строки находятся в разном порядке (и, возможно, с разными идентификаторами первичного ключа)? Если это не имеет большого значения, я могу отключить предупреждения в журнале ошибок (хотя это кажется неуклюжим).
В противном случае я могу быть вынужден полностью отказаться от двоичного журнала и просто полагаться на потенциально устаревшие полные резервные копии для плана восстановления.
Какие-нибудь советы в этой ситуации?
Формат репликации на основе строк фактически использует больше дискового пространства, чем формат репликации на основе операторов. Это просто, потому что в binlog у вас будут все данные, которые были вставлены / обновлены, а не только оператор. Итак, если оператор говорит вставить 100 строк, если binlog_format = STATEMENT вставит только один оператор, но если ROW фактически будет содержать все записи.
Итак, чтобы сэкономить место на диске, вам нужно вернуться к STATEMENT. В смешанном режиме mysql будет пытаться записать как ЗАЯВЛЕНИЕ в binlog, но в случае небезопасных операторов вернется к ROW основе. В вашем случае похоже, что у вас много небезопасных операторов, поэтому вы получаете бинлоги на основе ROW.
Вы можете сделать несколько вещей
оставьте его как ROW и выполните задание по очистке, которое очистит журналы через определенный период времени. Это необходимо для расчета того, что подходит для вашей системы. Перед тем, как удалить журналы, вы должны скопировать их в другое место, чтобы не потерять их.
реализовать репликацию через вторую систему и снова выполнить задание по очистке на главном устройстве (убедитесь, что подчиненное устройство синхронизировано, иначе вы можете потерять данные)
внимательно изучите потенциально опасные утверждения, для этого может потребоваться сотрудничество с разработчиками вашего приложения.