Запуск и обновление баз данных с минимальными затратами времени простоя и драматизма

Если вы когда-нибудь просыпались в 3 часа ночи из-за того, что кто-то запланировал обновление базы данных «в нерабочее время» (которое превратилось в пик хаоса), то вам знакомо это чувство. Ваш телефон загорается от панических сообщений, кофемашина молча вас осуждает, а где-то в канале Slack кто-то лихорадочно печатает «База данных уже работает?» заглавными буквами.

Вот хорошие новости: такие дни не обязательно должны быть вашим будущим.

Плохие новости? Они не исчезнут сами по себе. Время простоя базы данных очень похоже на ту стопку белья на вашем стуле — она становится хуже, чем дольше вы её игнорируете. Но в отличие от белья, обслуживание базы данных на самом деле решаемо с правильной стратегией, инструментами и небольшим планированием.

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

Синий/Зелёный развёртывание: дублёр вашей базы данных

Представьте себе синее/зелёное развёртывание как наличие дублера для вашей базы данных — и в отличие от Голливуда, этот на самом деле работает и стоит дешевле, чем кейтеринг.

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

Как это работает

Когда вам нужно выполнить обновление, миграцию или изменить схему:

1. Подготовка — Зелёная среда остаётся синхронизированной с Синей через асинхронную репликацию.
2. Обслуживание — Вы выполняете все свои основные задачи на Зелёной среде (изменение схемы, обновление версий, перестроение индексов).
3. Тестирование — Ваше приложение тщательно тестируется на Зелёной среде.
4. Переключение — Когда всё выглядит хорошо, вы переключаете производственный трафик на Зелёную среду.
5. Откат — Если что-то идёт не так, вы переключаетесь обратно на Синюю среду за секунды.

Преимущество здесь? Синька продолжает обслуживать производственный трафик на протяжении всего процесса. Ваши пользователи? Блаженно не знают. Ваш инженер на дежурстве? Наконец-то может спать.

Практическая реализация с захватом изменённых данных

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

Рабочий процесс:

-- На синей базе данных включите отслеживание изменений
ALTER DATABASE ВашаБазаДанных 
SET CHANGE_TRACKING = ON 
(CHANGE_RETENTION = 2 ДНЯ, AUTO_CLEANUP = ON);
-- Включите отслеживание изменений для конкретных таблиц
ALTER TABLE ВашаТаблица 
ENABLE CHANGE_TRACKING 
WITH (TRACK_COLUMNS_UPDATED = ON);
-- Запрос для получения изменений с последней синхронизации
DECLARE @synchronization_version bigint;
SET @synchronization_version = CHANGE_TRACKING_CURRENT_VERSION();
SELECT 
    CT.sys_change_id,
    CT.sys_change_operation,
    CT.sys_change_columns,
    T.*
FROM 
    CHANGETABLE(CHANGES ВашаТаблица, @last_sync_version) AS CT
INNER JOIN 
    ВашаТаблица AS T ON CT.[Id] = T.[Id]
ORDER BY 
    CT.sys_change_id;

Вместо того чтобы постоянно извлекать огромные объёмы данных, вы синхронизируете только то, что фактически изменилось. Для больших баз данных эта разница — пропасть между мелким неудобством и катастрофическим сбоем.

Стратегии нулевого простоя: выбор вашего оружия

Подход, который вы выберете, зависит от вашей технологии базы данных и вашей терпимости к операционной сложности. Давайте разберём основных участников:

1. Роллинг-апгрейды (способ TiDB)

Лучше всего подходит для: распределённых баз данных вроде TiDB.

Подход TiDB похож на ремонт дома путём исправления одной комнаты за раз, пока все продолжают жить там. Он обновляет компоненты в определённой последовательности:

1. Серверы Placement Driver (PD).
2. Серверы хранения TiKV.
3. Серверы TiDB SQL.

Результат? Бесперебойное обслуживание на протяжении всего обновления. Традиционные базы данных, напротив, используют техники «стоп-и-жди» — по сути, выключая весь дом, пока вы красите коридор.

2. Логическая репликация (чемпион PostgreSQL)

Лучше всего подходит для: баз данных PostgreSQL.

С PostgreSQL и активной-активной репликацией вы получаете то, что считается единственным по-настоящему беспробочным обновлением. Процесс:

# На основном узле создайте слот логической репликации
SELECT * FROM pg_create_logical_replication_slot('upgrade_slot', 'test_decoding');
# На резервном узле настройте его как реплика
SELECT slot_name FROM pg_replication_slots;
# Выполните обновление на реплике, не затрагивая основной
# Основной продолжает обслуживать трафик
pg_upgrade --old-datadir /var/lib/postgresql/14/main \
           --new-datadir /var/lib/postgresql/15/main \
           --link
# С опцией --link обновления происходят быстро
# Для огромных баз данных (даже 56 ТБ+) размер практически не влияет на процесс

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

3. Oracle GoldenGate с синим/зелёным

Лучше всего подходит для: баз данных Oracle и сложных схем.

Это премиальный вариант — сложный, мощный и да, более требовательный к эксплуатации. GoldenGate обеспечивает двунаправленную репликацию между синей и зелёной средами. Путь обновления:

1. Запустите двунаправленную репликацию (Синий ↔ Зелёный)
2. Поддерживайте Зелёную среду синхронизированной с Синей
3. Выполните обновление на Зелёной среде
4. Запустите проверки валидации
5. Переключите трафик приложения на Зелёную среду
6. Поддерживайте Синюю среду как резервное копирование в течение N часов
7. Демонтируйте Синюю среду

Создание вашего чек-листа обновлений: скучная, но важная часть

Прежде чем даже подумать о том, чтобы прикоснуться к базе данных, вот что на самом деле предотвращает звонки вам в 2 часа ночи:

Этап перед обновлением

Оценка и планирование

• Полностью задокументируйте текущую схему.
• Определите зависимости между базами данных.
• Отметьте любые пользовательские объекты (триггеры, хранимые процедуры, пользовательские типы).
• Перечислите все подключённые приложения.

Оценка данных и их очистка

• Проверьте целостность данных.
• Удалите устаревшие данные.
• Протестируйте преобразования данных, которые вам понадобятся.
• Задокументируйте любые проблемы с качеством данных.

Подготовка к тестированию

• Настройте изолированную тестовую среду, которая точно отражает производство.
• Включите реалистичные объёмы данных (вы будете удивлены, сколько проблем скрывается в небольших наборах данных).
• Создайте тестовые случаи для всех критических рабочих процессов.
• Задокументируйте базовые показатели производительности.

-- Пример: базовый тест производительности
DECLARE @StartTime datetime2 = GETDATE();
-- Ваш критический запрос здесь
SELECT COUNT(*) 
FROM ВашаБольшаяТаблица 
WHERE Статус = 'Активен' 
AND ДатаСоздания > DATEADD(MONTH, -6, GETDATE());
DECLARE @EndTime datetime2 = GETDATE();
PRINT 'Длительность запроса: ' + 
      CONVERT(varchar(20), DATEDIFF(MILLISECOND, @StartTime, @EndTime)) + ' мс';

Этап во время обновления

Мониторинг и журналирование

• Настройте дашборды мониторинга в реальном времени.
• Включите