Embed Size (px)
Citation preview
Disaster Recovery для Greenplum
Опыт разработки и внедрения решения для резервного копирования и восстановления БД Greenplum в банке
Тинькофф
Для чего нам нужно решение DR?
1. Продолжение предоставления сервиса внутренним заказчикам после потери всего контура СУБД («пожар» в ДЦ) без перерыва в обслуживании (High Availability)
2. Восстановление контура СУБД после его полной утраты вследствие сбоя (например, на новое железо)
3. Восстановление части данных при их утрате (потеря таблицы)
4. Перенос части нагрузки на резервный контур5. Регламентная проверка сделанных бэкапов
Архитектура DWH
GPDB 1
SAS
GPDB 2
ELT
End-usersAd-hoc, SAP, web-services
StorageELT
Стандартные способы DR
• gptransfer – копирует данные с одного контура на другой, не создаёт бекапы, связаны интерконнекты
• gp_dump/gp_restore – просто бэкапит/ресторит указанный объект в SQL-стейтменты
• Data Domain Boost – отдельное платное решение, трудно кастомизируется
• gpcrondump/gpdbrestore – наиболее близки к идеальному DR, обёртки вокруг gp_dump/gp_restore от вендора
Вариант 1
sdwN
. . .
Storage
Backup Restore
Local drive
sdw2
Local drive
sdw1
Local drive
sdwN
. . .
Local drive
sdw2
Local drive
sdw1
Local drive
NFS
NFS
NFS
NFS
NFS
NFS
Вариант 1
Чем не устроил этот вариант:• 3х96=288 потоков записи на хранилище – нужна быстрая и
дорогая СХД и канал к ней• При отказе одной из 24х точек монтирования NFS GP в
части случаев контур зависает• Бэкапы хранятся только на одной площадке – в случае
потери площадки мы их лишаемся
Вариант 2
sdwN
. . .
Backup Restore
Local drive
sdw2
Local drive
sdw1
Local drive
sdwN
. . .
Local drive
sdw2
Local drive
sdw1
Local drive
back
upba
ckup
back
up
SCP
SCP
SCP
Storage 2Storage 1
restorerestore
restore
rsync
NFSre
stor
e
Вариант 2
Плюсы:• Требования к СХД значительно более скромные• Бэкапы делаются на заведомо надёжные устройства• Бэкапы хранятся на обеих площадках
Минусы:• Бэкап и рестор больше афектят производительность
серверов GP• Объём СХД x2
Реализация
SAS ORACLE
sdwN
Local drive
sdwN
Local drive
back
uprestore
1.Постановка объекта в очередь
DR Server
2. Backup 3. Copy
SCP
4. Restore 5. Keep
Storage 2
keep
Сложности и нюансы
• Реализована гибкая многопоточность на каждом этапе• gp_dump – завершение процесса на мастере не означает
завершение бэкапа• gp_dump – объект необходимо указывать вместе с
партициями• При восстановлении таблицы в существующую truncate
может быть не выполнен из-за блокировок
Хранение бэкапов
• Уникальный ID бэкапа – ключ и имя объекта• Хранятся объекты за сегодня, вчера, крайний бэкап за
прошлую неделю и крайний бэкап за прошлый месяц• Информация о существующих бэкапах хранится в
ежедневно перестраиваемой внешней таблице GP• Удаляются бэкапы согласно представлениям в базе,
определяющим политику удаления
CREATE OR REPLACE VIEW prod_utl_md.v_backup_list_remove AS SELECT r.backup_dt, r.schema_name, r.table_name, r.backup_key FROM ONLY prod_utl_md.ext_backup_list_real r LEFT JOIN prod_utl_md.v_backup_list_actual a USING (backup_dt, schema_name, table_name, backup_key) LEFT JOIN prod_utl_md.v_backup_list_week w USING (backup_dt, schema_name, table_name, backup_key) LEFT JOIN prod_utl_md.v_backup_list_month m USING (backup_dt, schema_name, table_name, backup_key) WHERE (a.backup_key IS NULL AND w.backup_key IS NULL AND m.backup_key IS NULL) OR r.backup_dt < (date_trunc('month'::text, 'now'::text::date::timestamp with time zone) - '1 mon'::interval);
Архитектура DWH с DR
GPDB 1
SAS
GPDB 2
Source 1 Source 2 Source 3 Source 4
Hadoop
Informatica
End-usersAd-hoc, SAP
Web-services
Disaster Recovery
ONL SRC 1
ONL SRC 2ODS/O2G
Результаты
• Суточный объём репликации – 20 Тб, 6500 таблиц, всего – 3 миллиона объектов
• Пиковая скорость – до 3 Гбит/с• Задержка репликации – до 2 часов в пике• На контуре-приёмнике реализованы триггеры репликации
ключевых таблиц: завязаны построение и рассылка отчётов и т.д.
• Нагрузка локальных дисков суммарно увеличилась на 20-25%
• За счёт выноса локального хранилища на сегментах на отдельные диски удалось уменьшить её до 10-15%
• Отставание репликации СХД – около 4 часов• Баг в gp_dump, gpssh!
Мониторинг репликации
• SAS отсылает метрики в Graphite
Мониторинг репликации
Результаты
Другое использование DR
Prod 1 Prod 2
Dev Test
Аналогичным образом реализовано копирование объектов на всех четырёх существующих контурах. Это позволяет:
• Еженочно синхронизировать dev-среду целиком
• Разработчикам - синхронизировать отдельные таблицы на dev-среде так часто, как это нужно им
• Регламентно синхронизировать test-среду• В перспективе – использовать механизм DR для накатки релизов• Если на dev/test средах не нужны совсем свежие данные, есть возможность
наполнять их из бэкапов, на нагружая prod-среды
Планы на будущее
• Сделать возможным инкрементальный бэкап• Эволюция DR в полноценный Dual ETL• Использование механизмов DR для автоматизации
релизов
