2016-04-05 #PostgreSQLRussia TinkoffBank #2

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 для автоматизации

релизов