Резервирование больших данных

в 10:33, , рубрики: datawarehouse, Администрирование баз данных, базы данных, Блог компании «LifeStreet Media», бэкапы, хранилище данных, метки: , , ,

При проектировании и эксплуатации нашего хранилища данных, несколько раз возникал вопрос, как делать бэкапы или репликацию. Я на него неизменно давал один и тот же ответ — никак. Объясню немного почему.

Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.

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

Что же делать? Довольно давно мы придумали и реализовали механизм клонирования или мультиплексирования. Мы поддерживаем несколько «почти» идентичных систем, которые между собой никак не связаны, но загружают в себя одинаковые данные одинаковым образом. Поскольку в аналитические базы данных пользователи напрямую никогда ничего не пишут, это возможно сделать. Такое клонирование имеет еще одно важное преимущество: можно иметь одну или несколько тестовых систем с настоящими боевыми данными и нагрузкой. Еще одно преимущество — staging deployment и QA. Поведение системы с новой функциональностью можно сравнить с текущей боевой, и вовремя выловить ошибки.

Итак, клонирование дает возможность:

  • Иметь постоянно готовую живую резервную систему или несколько
  • Иметь идентичные системы разного предназначения или для распределения нагрузки
  • Иметь системы с одинаковыми данными, но разными настройками (например, оптимизированные под легкие или тяжелые запросы)
  • Иметь тестовую систему с боевыми данными и нагрузкой
  • Проводить постепенный деплоймент новой функциональности, уменьшая риск ошибок
  • Восстанавливать одну систему данными с другой (копированием)
  • Прозрачно всем этим управлять

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

Автор: alexzaitsev


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js