MariaDB: Правильный способ резервного копирования серверов-реплик

Вопрос или проблема

Мы управляем большим кластером MariaDB с MaxScale 24. Кластер состоит из одного основного сервера и двух серверов-реплик. Объем хранимых данных составляет ~240 ГБ.

Мы используем borgmatic для создания дампов баз данных каждый час. Резервные копии занимают около 30 минут каждая.

Интересуюсь, какие опции мне нужны для правильного резервного копирования сервера-реплики? Сам borgmatic в своей документации указывает, что следует использовать --single-transaction (документация), если наблюдаются ошибки при получении блокировок. У нас такие ошибки редко случаются по выходным (возможно, связаны с проверками).

Влияет ли опция --single-transaction на репликацию?

Почему мы используем borgmatic? Мы просто не нашли другого современного открытого средства. mariadb-backup не может (просто) восстановить отдельные базы данных. У нас 100 баз данных, и мы ни за что не хотим восстанавливать их все. Другие решения, такие как mysql-zrm, кажутся не поддерживающими официально mariadb, или они коммерческие. Кроме того, формат дампа значительно упрощает восстановление резервных копий. Это становится немного сложнее для инкрементных резервных копий.

.

Ответ или решение

Создание стратегий резервного копирования для серверов реплик MariaDB играет ключевую роль в защите данных и обеспечении отказоустойчивости системы. В вашем конкретном случае, где используется кластер MariaDB с MaxScale и borgmatic для регулярных дампов баз данных, необходимо рассмотреть несколько методов и их влияние на репликацию и доступность данных.

Теория

MariaDB предоставляет несколько встроенных инструментов для резервного копирования, таких как mariadb-dump и mariadb-backup. Однако, в зависимости от архитектуры вашей базы данных и ваших требований к восстановлению, выбор инструмента и методов резервного копирования может варьироваться. borgmatic является выбором, сделанным вами, что влечет за собой использования стандартного бинарного дампа базы данных.

Единичные транзакции и их влияние

Ключевая опция, упоминаемая вами, --single-transaction, позволяет сделать снимок состояния базы данных на момент начала резервного копирования для транзакционных таблиц (например, InnoDB) без блокировки на чтение других операций. Это особенно важно, когда вы имеете дело с высоконагруженными системами, поскольку минимизирует воздействие на производительность и риск блокировок.

Опция --single-transaction полезна, но стоит понимать, что она подходит только для InnoDB и не обеспечивает согласованность для не транзакционных таблиц, таких как MyISAM. Если в вашей конфигурации присутствуют такие таблицы, могут возникнуть проблемы с целостностью данных в случае восстановления.

Пример

Из вашего письма понятно, что вы используете borgmatic и испытываете проблемы с блокировками, возникающими время от времени, особенно в периоды высокой нагрузки (например, на выходных). Опция --single-transaction может уменьшить частоту этих проблем, так как снижает вероятность длительных блокировок таблиц.

Вы также отмечаете, что mariadb-backup не подходит из-за его ограничений в восстановлении отдельных баз данных. Это важный критерий выбора инструмента резервного копирования и восстановления, особенно учитывая большой объем данных и количество баз данных в вашей системе (~240 ГБ и 100 баз данных соответственно).

Применение

Теперь, когда у вас есть представление о том, как --single-transaction может помочь решить проблемы с блокировками, и вы понимаете ограничения borgmatic, рекомендуется следующая стратегия:

  1. Резервное копирование через реплики: Использование реплик для резервного копирования — это стандартная практика, позволяющая разгрузить основной сервер. Убедитесь, что реплики синхронизированы и, по возможности, выделите одну специально для резервного копирования.

  2. Использование других решений параллельно: Хотя вы нашли borgmatic как современный инструмент с функцией dump, можно изучить альтернативные подходы для бэкапа и восстановления отдельных баз данных, возможно, используя скрипты или сочетания других инструментов с возможностями выбора определенных данных. Это может включать такие утилиты, как MyDumper/MyLoader.

  3. Периодическое тестирование восстановления: Независимо от выбранного инструмента, крайне важно регулярно тестировать процесс восстановления данных. Это поможет удостовериться, что процедуры резервного копирования не повреждаются и данные можно будет легко восстановить по мере необходимости.

  4. Оцените улучшения borgmatic: Следите за обновлениями и функциями borgmatic, так как новые версии могут добавить недостающие функции, которые улучшат процесс резервного копирования.

  5. Мониторинг и планирование: Изучите использование инструментов мониторинга, чтобы заранее предупредить потенциальные конфликты или проблемы с блокировкой и согласовать процессы резервного копирования с временем низкой интенсивности использования кластера.

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

Оцените материал
Добавить комментарий

Капча загружается...