Резервное копирование и восстановление - это критически важная функциональность для любой системы управления базами данных. Она обеспечивает возможность восстановления системы после сбоев, повреждения данных или для миграции между кластерами. В StarRocks основным и наиболее полным инструментом для этой цели служат операторы BACKUP и RESTORE.
При этом, возможности и подход к резервному копированию кардинально различаются в зависимости от базовой архитектуры кластера: классической Shared-Nothing или современной Shared-Data.
Ключевое различие Shared-Nothing и Shared-Data
Архитектура Shared-Nothing (Классическая)
Это традиционная архитектура StarRocks. В такой системе данные реплицируются и хранятся непосредственно на узлах Backend (BE). Процесс резервного копирования здесь является встроенной функцией самой базы данных.
Операции BACKUP и RESTORE поддерживается в полном объеме. Вы можете создавать снапшоты (мгновенные снимки) таблиц, разделов и даже целых баз данных и выгружать их во внешнее хранилище.
Архитектура Shared-Data (Lakehouse)
В этой современной архитектуре разделения хранения данных и вычислений хранилище данных (Storage) отделено от вычислительных ресурсов (Compute Nodes или CN). Фактически, данные уже находятся в удаленном объектном хранилище (S3, GCS, OSS и т.д.).
Операции BACKUP и RESTORE официально не поддерживаются. Они недоступны для кластеров Shared-Data.
Стратегия резервного копирования для Shared-Data
Поскольку сами данные уже находятся в управляемом вами объектном хранилище, которое обычно обеспечивает 11 девяток надежности, стратегия резервного копирования смещается.
Бэкап метаданных: Самый критичный компонент для восстановления – это метаданные и каталоги. Их можно и нужно бэкапить стандартными инструментами или API.
Snapshot на уровне хранилища: Разработчики StarRocks предлагают концепцию использования снапшотов на уровне объекта хранилища (например, S3 Snapshots). Это более эффективный и быстрый способ создания резервных копий всей "базы данных" в такой архитектуре, так как не требует перемещения данных через вычислительный слой.
Ручное восстановление: В случае глобальной катастрофы потребуется развернуть новый кластер Shared-Data и "подключить" его к тому же бакету в S3.
Существует несколько подходов бэкапа метаданных и создания снэпшотов.
Ручной скриптовый бэкап: экспорт через SQL
Это базовый и наиболее доступный метод для всех версий StarRocks. С помощью SQL-запросов вы выгружаете информацию об объектах схемы данных (DDL — определение структур БД, таблиц, представлений) в файлы.
Выгрузка DDL: Пишется скрипт (чаще всего на Python, Shell или Java), который подключается к кластеру StarRocks и выполняет команду SHOW CREATE TABLE my_table;. Результат сохраняется в текстовый файл.
Сбор метаданных из Information Schema: База данных information_schema хранит ценнейшие метаданные: имена и структуру таблиц, названия колонок и их типы, а также информацию о правах доступа. Вы можете выгружать эти данные в формате CSV, чтобы при необходимости быстро восстановить информацию о любом объекте кластера.
Это идеальный метод для регулярного, автоматизированного бэкапа только структуры данных. Он легковесный и не зависит от версии продукта.
FE-специфичный бэкап (для платформ вроде Kubernetes)
Этот метод – следующий уровень сложности. Вы можете автоматизировать бэкап, работая напрямую с файловой системой узлов Frontend (FE) или используя API платформы, на которой запущен StarRocks (например, Kubernetes).
Автоматизированный бэкап: Системный администратор может настроить задачу (cron job), которая будет периодически копировать директорию с метаданными FE (meta_dir) в надежное место, например, в S3 или на отдельный диск. Этот подход «снаружи» базы данных позволяет создавать полные и консистентные бэкапы всего состояния FE.
Восстановление: Сценарий восстановления предполагает развертывание нового кластера и передачу ему пути до этого бэкапа. На современных платформах вроде Kubernetes этот процесс становится еще более управляемым, а его аварийное восстановление — предсказуемым.
Этот метод подходит для максимальной надежности - на уровне всего кластера его состояние перемещается на новое место.
Кластерные снимки (Cluster Snapshot)
Это самый технологичный и рекомендуемый способ для новых версий. Начиная с StarRocks 3.5, для архитектуры Shared-Data была введена концепция Cluster Snapshot (кластерного снимка), которая знаменует собой переход от устаревших команд BACKUP/RESTORE к новой, более эффективной парадигме.
Автоматизация: Вам не нужно писать скрипты. Система делает всё сама: после включения (ADMIN SET AUTOMATED CLUSTER SNAPSHOT ON) она будет автоматически создавать полные снимки состояния кластера с заданной периодичностью (по умолчанию — раз в 10 минут).
Что попадает в снимок: Снэпшот сохраняет полное состояние кластера: все каталоги (CATALOGS), базы данных, таблицы, представления, UDF (пользовательские функции), а также информацию о пользователях и их привилегиях.
Экономия места: Снэпшот не делает копию самих данных (которые уже лежат в S3), записывая только их актуальную версию на определенный момент времени. По умолчанию система хранит только один последний снэпшот, чтобы минимизировать затраты на хранение.
Быстрое восстановление: Процесс восстановления — это просто вопрос указания нового или существующего кластера на путь к снэпшоту в объектном хранилище. Система сама загрузит метаданные и подключится к нужным версиям данных. Перемещения данных не требуется, поэтому восстановление занимает минуты, а не часы.
Этот способ рекомендуется для всех, кто работает на StarRocks 3.5+. Он прост в настройке, эффективен и обеспечивает надежную защиту всей системы.
Резервные копии в Shared-Nothing
Механизм работы (Snapshot-based)
Резервное копирование в StarRocks основано на создании снапшотов (мгновенных снимков) данных. Процесс выглядит следующим образом:
Создание снапшота (BACKUP): Вы инициируете команду, которая замораживает состояние таблицы или раздела на определенный момент времени, создавая локальный слепок данных.
Перемещение в Repository: Созданный снапшот вместе с метаданными (структура таблицы, информация о разделах и т.д.) асинхронно загружается в предварительно настроенный Repository – ваше внешнее хранилище (S3, HDFS, GCS).
Восстановление (RESTORE): Команда RESTORE извлекает снапшот из Repository в ваш (или другой) кластер StarRocks. При этом вы можете восстановить данные как в исходное состояние, так и переименовать таблицу или базу данных, а также указать желаемый replication_num для реплик.
Глубина резервного копирования: что поддерживается
Начиная с версии 3.4.0, возможности резервного копирования значительно расширились:
Данные OLAP-таблиц: Таблицы любых типов (Duplication, Aggregate, Primary Key, Unique), разделы.
Метаданные External Catalog: Поддерживается бэкап метаданных внешних каталогов (например, Hive, Iceberg).
Materialized Views (MV): Как синхронные, так и асинхронные материализованные представления.
Логические представления (Views) и пользовательские функции (UDF): Также включены в процесс бэкапа.
Работа с открытыми форматами данных (Iceberg, Parquet, Paimon)
Это важный момент для понимания: резервное копирование BACKUP в StarRocks предназначено для бэкапа внутренних таблиц StarRocks в их собственном внутреннем формате. Оно не делает "слепок" файлов Parquet или Iceberg.
Что это значит на практике:
External Catalog: Когда вы используете операцию BACKUP для таблицы в Iceberg Catalog, StarRocks сохраняет в бэкап метаданные этой таблицы: ее схему, расположение файлов в S3/HDFS, настройки партиционирования и т.д.
Сами данные: Файлы данных, которые уже лежат в вашем storage (например, Parquet-файлы в бакете S3 для Iceberg таблицы), не копируются повторно. Во время создания резервной копии через операцию BACKUP они не перемещаются. Во время RESTORE восстанавливаются только метаданные, указывая на те же самые файлы данных, которые были там изначально.
Для самих данных в открытых форматах ответственность за резервное копирование лежит на уровне их собственных систем хранения (S3, HDFS). StarRocks создаёт резервные копии только для "прослойки" – метаданные, необходимые для работы с данными.
Инкрементальное (дельта) резервное копирование
В текущей версии встроенный механизм BACKUP не поддерживает истинное инкрементное резервное копирование (когда копируются только изменения с прошлого бэкапа). Он всегда создает полный снапшот.
Стратегия для реализации дельта-бэкапов:
StarRocks предоставляет обходной путь через правильное проектирование таблицы:
Динамические партиции: Необходимо создать таблицу с динамическими партициями (например, по дням).
Бэкап по партициям: Вы можете выполнять BACKUP только для новых партиций (например, для вчерашнего и сегодняшнего дня), которые еще не были зарезервированы. Таким образом, вы создаете "цепочку" полных бэкапов, но каждый последующий бэкап содержит только новые данные, что имитирует поведение инкрементального подхода и значительно экономит время и место.
Объем резервных копий: ожидания и реальность
Это зависит от нескольких факторов:
Фактор сжатия: StarRocks внутренне хранит данные в сжатом виде. Размер резервной копии будет близок к размеру сырых сжатых данных на дисках BE. Дополнительного сжатия при создании бэкапа не происходит.
Количество реплик: Бэкап создается на уровне таблицы, но в репозиторий выгружается только одна копия (один экземпляр) данных.
Пример с таблицей в 100 Гб:
Предположим, ваша таблица занимает 100 Гб на диске (уже со всеми репликами, например, replication_num=3 означает ~300 Гб общего потребления на кластере).
Размер резервной копии такой таблицы будет приблизительно равен одной трети от её размера, т.е. около 33 Гб.
Это значительно экономит место в хранилище бэкапов, по сравнению с переносом всех трех реплик.
Поддержка распределенных хранилищ (S3, HDFS)
StarRocks поддерживает создание репозиториев (repository) в большинстве популярных распределенных систем хранения.
Резервное копирование в несколько хранилищ: В одной команде BACKUP можно указать только один репозиторий.
Стратегия 3-2-1: Для обеспечения отказоустойчивости самих бэкапов рекомендуется создавать несколько репозиториев и запускать BACKUP для каждого из них в разные хранилища. Например, создать два разных Repository (один на S3, другой на HDFS) и настроить запуск бэкапов в оба. Затем на уровне инфраструктуры включить репликацию между бакетами S3.
Чтение бэкапа: RESTORE может читать данные из Repository, созданного другим кластером, что упрощает миграцию.
Резервное копирование настроек StarRocks и внешних ссылок
Это один из наиболее уязвимых моментов, часто упускаемый из виду. Встроенные BACKUP и RESTORE НЕ делают бэкап конфигурации самого кластера (параметров FE, BE, CN).
Что нужно бэкапить вручную:
Конфигурационные файлы: fe/conf/fe.conf, be/conf/be.conf, cn/conf/cn.conf (если есть) всех нод кластера. Версионируйте их в Git.
Метаданные FE (собственные): Путь, указанный в meta_dir в fe.conf (обычно meta). Это жизненно важные данные для самого кластера.
Репозитории бэкапов: Сами файлы бэкапов в S3/HDFS, которые были созданы командами BACKUP.
External Catalog ссылки: Метаданные о том, как подключен ваш кластер к Hive Metastore, Iceberg, Paimon, сохраняются в бэкапе начиная с версии 3.4. При восстановлении через RESTORE ... ALL EXTERNAL CATALOGS они будут восстановлены, при условии, что вы также скопировали сами файлы данных этих каталогов (например, Parquet в S3).
Планирование Disaster Recovery Plan (DRP)
Для разработки реального DRP необходимо уметь оценивать время выполнения операций.
Оценка времени резервного копирования (Backup Time)
Общее время = Время снапшота + Время загрузки в Repository
Время снапшота: Обычно занимает от нескольких секунд до нескольких минут. Это операция над метаданными, создающая "замороженное" состояние.
Время загрузки: Это доминирующий фактор. Оно линейно зависит от объема измененных данных, количества и размера таблетов, а также скорости сети от BE до вашего Repository (S3/HDFS).
Примерная формула: Transfer Time ≈ (Размер_бэкапа в ГБ * 1024) / (Скорость_сети в МБ/сек).
Пример: Данные 100 Гб, сеть 100 МБ/сек, фактор 1.0. -> Transfer Time ≈ (100 * 1024) / 100 = 1024 секунды ≈ 17 минут.
Используйте параллельную загрузку. StarRocks сама загружает таблеты параллельно с разных BE.
Оценка времени восстановления (Restore Time)
Общее время = Время планирования (metadata) + Время скачивания из Repository
Время планирования: FE сканирует репозиторий, чтобы найти нужный снапшот и спланировать, куда восстанавливать таблеты. Обычно занимает несколько минут.
Время скачивания: Аналогично времени загрузки, но требует учитывать:
Распределение ввода-вывода: Если вы восстанавливаетесь на новый пустой кластер, BE будут скачивать данные параллельно с нескольких узлов.
Затраты на создание реплик: После скачивания данных на одну копию, StarRocks сама склонирует необходимые реплики в фоне. Это время можно оценить как Transfer Time для одной копии, а остальные будут созданы автоматически с меньшей скоростью.
Таким образом, для оценки RTO и RPO вашего DRP, за основу расчета времени (RTO) можно брать Transfer Time для вашего самого большого раздела или таблицы, плюс время на развертывание нового кластера и подгрузку конфигураций.
Резюме: ключевые выводы
Shared-Data vs Shared-Nothing: Резервное копирование (BACKUP/RESTORE) работает только в Shared-Nothing. Для Shared-Data используйте снапшоты самого объектного хранилища.
Формат данных: BACKUP создает копии внутренних OLAP-таблиц. Для External Catalog (Iceberg, Parquet) резервируются только метаданные, а не сами файлы данных.
Инкрементальные бэкапы: Встроенных нет. Используйте стратегию с динамическим партиционированием, чтобы бэкапить только новые разделы.
Объем бэкапа: Будет примерно в 3 раза меньше (т.к. копируется одна реплика из трех), чем живой размер данных на кластере. Для таблицы 100 Гб ~ 33 Гб.
Распределенное хранилище: Для резервирования бэкапов используйте несколько репозиториев или включите репликацию на уровне storage.
Конфигурация кластера: BACKUP не сохраняет настройки самого StarRocks (FE/BE конфиги). Это нужно делать отдельно, используя системы управления конфигурациями (Ansible, Git).
DRP: Время восстановления линейно зависит от объема данных и скорости сети. За основу расчета возьмите Transfer Time для самой большой партиции данных.