Делаем резервное копирование кластера ClickHouse: простая инструкция

Меня зовут Леонид Блынский и я администратор баз данных в Лиге Цифровой Экономики. В этой небольшой статье расскажу, как я делаю резервное копирование кластера ClickHouse размером 20 ТБ.

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

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

Для стенда разработки мы сделали возможность создания локальных бэкапов. В файле настроек /etc/clickhouse-server/config.d/backup_disk.xml

потребовалось прописать разрешенный путь для бэкапа:

<clickhouse> <storage_configuration>     <disks>         <backups>             <type>local</type>                 <path>/var/lib/clickhouse/backups</path>         </backups>     </disks> </storage_configuration> <backups>         <allowed_disk>backups</allowed_disk>     <allowed_path>/var/lib/clickhouse/backups/</allowed_path> </backups> </clickhouse>

Разработчики и аналитики теперь могли сохранить данные перед какими-либо необратимыми действиями:

backup table main.dim_account TO Disk('backups', ' main.dim_account.zip')

Ключевое слово Disk следует писать с большой буквы:)

Или так, для бэкапа всей БД:

backup database main TO Disk('backups', ' main_dev.zip')

Мы проверили — восстановиться просто, все работает отлично:

restore table main.dim_account AS main.dim_account FROM Disk('backups', ' main.dim_account.zip')

Далее мы настроили хранилище S3 для хранения бэкапа нашей БД. Команда для запуска стала выглядеть так:

backup table main.dim_account to S3('http://10.10.10.10:9000/clickhouse/ main.dim_account.zip','bkp_user','bkp_pwd');

Далее мы попробовали вручную забэкапить все таблицы базы. Все шло хорошо, пока не пришла очередь самой большой таблицы размером около 3 ТБ. В какой-то момент стала выпадать ошибка:

_{<Fatal> BaseDaemon: Received signal Segmentation fault (11)
<Fatal> BaseDaemon: Address: 0x7f0ba8a00960 Access: write. Address not mapped to object.
<Fatal> BaseDaemon: Stack trace: 0x7f7ab25479e6 ………………….}

Ошибка возникала случайным образом: таблица то бэкапилась, то нет. Поиск на форумах ни к чему не привел. 

Так как с другими таблицами проблем не возникало, мы сделали вывод, что проблема именно в размере, потому и надо что-то придумать, чтобы уменьшить размер резервной копии в одной команде.

Оказалось, что таблица секционирована, а ClickHouse замечательно умеет делать резервные копии отдельных партиций.

В нашем кластере 6 узлов и несколько конфигураций баз данных: база allrp (имеет реплики на всех шести узлах), main (3 шарда, и каждый шард имеет две реплики). 

Для бэкапа allrp достаточно снять копию только с одного узла. Для резервного копирования main требуется снять копию c трех узлов. То есть надо зайти на все хосты, где располагаются шарды, сгенерировать  и выполнить команды бэкапа.

Немного вспомнив язык SQL, мы явили на свет скрипт генерации команд бэкапа по партициям:

select distinct 'backup table ' || database || '.' || table || '  partition ''' || partition || ''' to S3(''http://10.10.10.10:9000/clickhouse/' || formatDateTime(now(),   '%d-%m-%Y')|| '/main.' || table || '.' || partition || '-shard-' || q2.shard || '.zip'',''bkp_user'',''bkp_pwd'');' as backup_command FROM   system.parts,   (   select          toString(shard_num) as shard   from          system.clusters   where          host_address = '127.0.0.1'          and cluster = 'main') q2 where active   and database = 'main'   and table in ('fct_bigtable') group by   database,   table,   partition,s   q2.shard

Все скрипты бэкапа по партициям отрабатывают успешно, таблицу можно восстановить.

Так как остальные таблицы не вызывали проблем, то их бэкапим уже целиком:

select * from   (   select          distinct 'backup table ' || database || '.' || table || '  to S3(''http://10.10.10.10:9000/clickhouse/' || formatDateTime(now(),          '%d-%m-%Y')|| '/main.' || table || '-shard-' || q2.shard || '.zip'',''bkp_user'',''bkp_pwd'');'   from          system.parts,          (          select                toString(shard_num) as shard          from                system.clusters          where                host_address = '127.0.0.1'                and cluster = 'main') q2   where          active          and database = 'main'          and table not like 'fct_bigtable%' ) q1

Данные SQL надо выполнить на каждом узле с уникальными шардами (в нашем примере на трех) и на этих же узлах запустить сгенерированные команды. Для сохранения результата запроса в файл можно последней строчкой дописать:

INTO OUTFILE '/var/lib/clickhouse/backups/backup.sql' FORMAT TabSeparatedRaw; 

Для бэкапа базы allrp генерируем команды, которые надо запустить на любом узле:

select   distinct 'backup table ' || database || '.' || table || '  to S3(''http://10.10.10.10:9000/clickhouse/' || formatDateTime(now(),   '%d-%m-%Y')|| '/allrp.' || table || '.zip'',''bkp_user'',''bkp_pwd'');' from   system.parts where   active   and database = 'allrp'; 

Наблюдать за работой процесса резервного копирования и его статусом можно так:

select * from system.backups_distributed

После того как нам удалось в ручном режиме проводить полноценный бэкап базы данных, начался этап автоматизации. Мы привлекли разработчика Python — он за пару дней реализовал задачи в Airflow, которые генерируют команды бэкапа, запускают их, отслеживают выполнение и в случае аварии отдельных команд ставят их в очередь снова. То есть бэкап стало возможным пускать по расписание или «по нажатию кнопки» в Airflow.

После успешного выполнения бэкапа инфоруется команда поддержки. Кроме того, на логи работы бэкапа мы прикрутили Grafana. В ней видим информацию о последних бэкапах, время выполнения, размер, а также случившиеся ошибки. С помощью распараллеливания команд резервного копирования нам удалось сократить время бэкапа с 40 до 18 часов.

Как результат — вполне стабильный инструмент с интерфейсом, визуализацией работы и мониторингом, который можно полностью контролировать.

Ранее мы рассказывали, как работать со словарями данных и оптимизировать запросы и распределенными таблицами в ClickHouse. Возможно, это тоже будет полезно.