При проектировании и эксплуатации нашего хранилища данных, несколько раз возникал вопрос, как делать бэкапы или репликацию. Я на него неизменно давал один и тот же ответ — никак. Объясню немного почему.
Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.
Иногда для поддержания резервной системы используют репликацию. Но надо понимать, что репликация довольно сильно просаживает производительность, так как требует записи бинарного лога, а если репликация синхронная, то и синхронизации. В аналитических приложениях с большим потоком данных, когда требуется постоянно грузить в базу данных тысячи или десятки тысяч записей в секунду, это может быть неприемлимо.
Что же делать? Довольно давно мы придумали и реализовали механизм клонирования или мультиплексирования. Мы поддерживаем несколько «почти» идентичных систем, которые между собой никак не связаны, но загружают в себя одинаковые данные одинаковым образом. Поскольку в аналитические базы данных пользователи напрямую никогда ничего не пишут, это возможно сделать. Такое клонирование имеет еще одно важное преимущество: можно иметь одну или несколько тестовых систем с настоящими боевыми данными и нагрузкой. Еще одно преимущество — staging deployment и QA. Поведение системы с новой функциональностью можно сравнить с текущей боевой, и вовремя выловить ошибки.
Итак, клонирование дает возможность:
- Иметь постоянно готовую живую резервную систему или несколько
- Иметь идентичные системы разного предназначения или для распределения нагрузки
- Иметь системы с одинаковыми данными, но разными настройками (например, оптимизированные под легкие или тяжелые запросы)
- Иметь тестовую систему с боевыми данными и нагрузкой
- Проводить постепенный деплоймент новой функциональности, уменьшая риск ошибок
- Восстанавливать одну систему данными с другой (копированием)
- Прозрачно всем этим управлять
И все это без штрафов по производительности, и с минимальными рисками. Такой подход многократно нам очень помогал. Более того, он позволял нам иметь системы на разных базах данных, но работающие по одинаковым алгоритмам. Тем самым упрощая миграцию с одной базы данных на другую.
Автор: alexzaitsev
