Главная » Linux

Clickhouse: резервное копирование и восстановление

На чтение: 21 минОпубликовано: Обновлено:
Содержание
  1. Введение
  2. Запуск в Docker
  3. Резервное копирование Clickhouse
  4. Принцип работы
  5. Создание копии и ручное восстановление
  6. Автоматическое восстановление через clickhouse-backup
  7. Установка
  8. Настройка
  9. Создание резервной копии
  10. Восстановление резервной копии
  11. Создание резервной копии по расписанию через crontab
  12. Заключение
  13. Используемые источники

Введение

В статье будет рассказано про одну из популярных СУБД в последнее время от российского разработчика Yandex под названием Clickhouse. Свою популярность данная база сыскала благодаря возможности быстрой выборки данных засчёт хранения данных “столбцом” с привязкой ко времени, а не “строками”, как в классических реляционных СУБД (MySQL или POstgreSQL, например).

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

В статье же будет сделан основной акцент на резервное копирование базы кликхауса и её восстановление. В рамках данной статьи, clickhouse версии 20.3 будет запущен в докер и все дальнейшие манипуляции будут осуществляться с контейнером. Но это не принципиально, подойдет и классическая установка.

Запуск в Docker

  • Хранение данных кликхауса будет в директории /storage/${CONTAINER_NAME}/clilckhouse, которая будет создана при старте контейнера (владелец – пользователь clickhouse). Создать директорию для хранения конфига:
CONTAINER_NAME=clickhouse
mkdir -p /storage/${CONTAINER_NAME}/etc/clickhouse-server
  • Сгенерировать пароль и хеш для root-пользователя (хеш запомнить):
PASSWORD=$(base64 < /dev/urandom | head -c8); echo "$PASSWORD"; echo -n "$PASSWORD" | sha256sum | tr -d '-'
  • Подготовить основной файл конфигурации config.xml:
cat > /storage/${CONTAINER_NAME}/etc/clickhouse-server/config.xml << EOF
<?xml version="1.0"?>
<yandex>
    <logger>
        <level>warning</level>
        <log>/clickhouse/data/clickhouse-server.log</log>
        <errorlog>/clickhouse/data/clickhouse-server-error.log</errorlog>
        <size>10M</size>
        <count>4</count>
        <console>1</console>
    </logger>
 
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
 
    <openSSL>
        <server> <!-- Used for https server AND secure tcp port -->
            <certificateFile>/etc/clickhouse-server/server.crt</certificateFile>
            <privateKeyFile>/etc/clickhouse-server/server.key</privateKeyFile>
            <dhParamsFile>/etc/clickhouse-server/dhparam.pem</dhParamsFile>
            <verificationMode>none</verificationMode>
            <loadDefaultCAFile>true</loadDefaultCAFile>
            <cacheSessions>true</cacheSessions>
            <disableProtocols>sslv2,sslv3</disableProtocols>
            <preferServerCiphers>true</preferServerCiphers>
        </server>
        <client> <!-- Used for connecting to https dictionary source -->
            <loadDefaultCAFile>true</loadDefaultCAFile>
            <cacheSessions>true</cacheSessions>
            <disableProtocols>sslv2,sslv3</disableProtocols>
            <preferServerCiphers>true</preferServerCiphers>
            <invalidCertificateHandler>
                <name>RejectCertificateHandler</name>
            </invalidCertificateHandler>
        </client>
    </openSSL>
 
    <interserver_http_port>9009</interserver_http_port>
 
    <listen_host>0.0.0.0</listen_host>
    <listen_try>1</listen_try>
 
    <max_connections>4096</max_connections>
    <keep_alive_timeout>3</keep_alive_timeout>
 
    <max_concurrent_queries>100</max_concurrent_queries>
 
    <uncompressed_cache_size>8589934592</uncompressed_cache_size>
 
    <mark_cache_size>5368709120</mark_cache_size>
 
    <path>/clickhouse/</path>
 
    <tmp_path>/clickhouse/tmp/</tmp_path>
 
    <user_files_path>/var/lib/clickhouse/user_files/</user_files_path>
 
    <users_config>users.xml</users_config>
 
    <default_profile>default</default_profile>
 
    <default_database>default</default_database>
 
    <timezone>Europe/Moscow</timezone>
 
    <!-- <umask>022</umask> -->
 
    <mlock_executable>false</mlock_executable>
 
    <remote_servers>
        <!-- Test only shard config for testing distributed storage -->
        <test_shard_localhost>
            <shard>
                <replica>
                    <host>localhost</host>
                    <port>9000</port>
                </replica>
            </shard>
        </test_shard_localhost>
        <test_cluster_two_shards_localhost>
             <shard>
                 <replica>
                     <host>localhost</host>
                     <port>9000</port>
                 </replica>
             </shard>
             <shard>
                 <replica>
                     <host>localhost</host>
                     <port>9000</port>
                 </replica>
             </shard>
         </test_cluster_two_shards_localhost>
        <test_shard_localhost_secure>
            <shard>
                <replica>
                    <host>localhost</host>
                    <port>9440</port>
                    <secure>1</secure>
                </replica>
            </shard>
        </test_shard_localhost_secure>
        <test_unavailable_shard>
            <shard>
                <replica>
                    <host>localhost</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <replica>
                    <host>localhost</host>
                    <port>1</port>
                </replica>
            </shard>
        </test_unavailable_shard>
    </remote_servers>
 
    <zookeeper incl="zookeeper-servers" optional="true" />
 
    <macros incl="macros" optional="true" />
 
    <builtin_dictionaries_reload_interval>360</builtin_dictionaries_reload_interval>
 
    <max_session_timeout>3600</max_session_timeout>
 
    <default_session_timeout>60</default_session_timeout>
 
    <!--
    <graphite>
        <host>localhost</host>
        <port>42000</port>
        <timeout>0.1</timeout>
        <interval>60</interval>
        <root_path>one_min</root_path>
        <hostname_in_path>true</hostname_in_path>
 
        <metrics>true</metrics>
        <events>true</events>
        <asynchronous_metrics>true</asynchronous_metrics>
    </graphite>
    <graphite>
        <host>localhost</host>
        <port>42000</port>
        <timeout>0.1</timeout>
        <interval>1</interval>
        <root_path>one_sec</root_path>
 
        <metrics>true</metrics>
        <events>true</events>
        <asynchronous_metrics>false</asynchronous_metrics>
    </graphite>
    -->
 
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <!--
            PARTITION BY expr https://clickhouse.yandex/docs/en/table_engines/custom_partitioning_key/
            Example:
                event_date
                toMonday(event_date)
                toYYYYMM(event_date)
                toStartOfHour(event_time)
        -->
        <partition_by>toYYYYMM(event_date)</partition_by>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </query_log>
 
    <!-- Uncomment if use part_log
    <part_log>
        <database>system</database>
        <table>part_log</table>
 
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </part_log>
    -->
 
    <dictionaries_config>*_dictionary.xml</dictionaries_config>
 
    <compression></compression>
 
    <distributed_ddl>
        <path>/clickhouse/task_queue/ddl</path>
    </distributed_ddl>
 
    <merge_tree>
        <max_suspicious_broken_parts>5</max_suspicious_broken_parts>
        <enable_mixed_granularity_parts>1</enable_mixed_granularity_parts>
    </merge_tree>
 
    <format_schema_path>/var/lib/clickhouse/format_schemas/</format_schema_path>
</yandex>
EOF
  • Пользовательский users.xml, где будет создан один пользователь – root_user. Обратить внимание, что вместо пароля для root_user рекомендуется вписывать хеш в password_sha256_hex, полученный в самом начале при генерации пароля:
cat > /storage/${CONTAINER_NAME}/etc/clickhouse-server/users.xml << EOF
<yandex>
    <profiles>
        <default>
            <max_memory_usage>10000000000</max_memory_usage>
            <use_uncompressed_cache>0</use_uncompressed_cache>
            <load_balancing>random</load_balancing>
        </default>
        <system_user>
            <max_memory_usage_for_user>4294967296</max_memory_usage_for_user>
            <max_memory_usage_for_all_queries>4294967296</max_memory_usage_for_all_queries>
            <max_execution_time>300</max_execution_time>
            <timeout_before_checking_execution_speed>15</timeout_before_checking_execution_speed>
        </system_user>
        <readonly>
            <readonly>1</readonly>
        </readonly>
    </profiles>
    <users>
        <root_user>
            <password_sha256_hex>864a31d1c785d7f198cbe485d18020af645c2569ef27225006b26aa0fb1e8b09</password_sha256_hex>
            <networks>
                <ip>::/0</ip>
            </networks>
            <profile>default</profile>
            <quota>default</quota>
        </root_user>
    </users>
    <quotas>
        <default>
            <interval>
                <duration>3600</duration>
                <queries>0</queries>
                <errors>0</errors>
                <result_rows>0</result_rows>
                <read_rows>0</read_rows>
                <execution_time>0</execution_time>
            </interval>
        </default>
    </quotas>
</yandex>

По умолчанию используется дефолтный profile с именем default, в котором указаны различные параметры, которые будут применены ко всем пользователям с профилем default, т.е. для root_user. При необходимости создаются пользователи для каждой БД с дефолтным profile, если нет иных особенных требований.

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

docker run -d --name ${CONTAINER_NAME} \
-p 8123:8123 -p 9000:9000 \
--restart=always \
-h ${CONTAINER_NAME} \
-v /storage/${CONTAINER_NAME}/etc/clickhouse-server:/etc/clickhouse-server \
-v /storage/${CONTAINER_NAME}/clickhouse:/clickhouse \
yandex/clickhouse-server:20.3

По умолчанию данные клика хранятся по пути /var/lib/clickhouse если запускать без докера, но в рамках данной статьи директория с данными располагается по пути /clickhouse внутри контейнера, и этот же путь прописан в конфиге. Это непринципиальный момент, но стоит иметь ввиду, чтобы не запутаться.

На этом запуск завершён и можно приступать к работе с кликхаус.

Выполнить подключение внутрь контейнера:

docker exec -it clickhouse bash

Через консольный клиент проверить, что кликхаус встречает смайликом :) 

clickhouse-client --host=127.0.0.1 -m -u root_user --ask-password

ClickHouse client version 20.3.21.2 (official build).
Connecting to 127.0.0.1:9000 as user root_user.
Connected to ClickHouse server version 20.3.21 revision 54433.

clickhouse :)

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

Резервное копирование Clickhouse

Принцип работы

Далее будет рассмотрено, как сделать бэкап кликхауса. Спойлер: весьма нетривиально. В Clickhouse нет возможности использования классических инструментов mysqldump или pg_dump, знакомых по реляционным СУБД MySQL или PostgreSQL. Физически база данных в Clickhouse оперирует не таблицами, а партициями – частями таблиц, которые объединены по одному из критериев. Например, по дням или месяцам. Таким образом, при выборке используется лишь необходимая партиция. На основе этого и выполняется резервное копирование.

Бэкап  создается через команду alter table freeze table_name и представляет из себя hardlink (указывает на текущие файлы БД), который создается по пути ${clickhouse_dir}/shadow. После каждого выполнения команды alter table freeze table_name, в shadow появляется директория, которая увеличивается на единицу, а также выполняется команда chmod, которая убирает права на изменение, т.е. хардлинки доступны только для чтения. Напоминаю, что данные в кликхаусе не изменяются (как правило), а поэтому дальнейшие операции по организации резервирования выполняются уже непосредственно с хардлинками.

Запрос “заморозки” таблиц выполняется почти мгновенно, но ждет завершения всех запросов к таблице, для которой выполняется freeze.

Создание копии и ручное восстановление

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

Для понимания, ниже разобран пошагово наглядный пример создания резервной копии тестовой БД temp и таблицы test.

  • Создать БД с именем temp, таблицу с именем test, указав создание партиций по полю date и наполнить её тестовыми данными:
create database temp
 
CREATE TABLE IF NOT EXISTS temp.test
(
  `date` Datetime,
  `user_id` String,
  `pageviews` Int32
)
ENGINE = MergeTree()
PARTITION BY toStartOfHour(date)
ORDER BY (date)
 
INSERT INTO temp.test VALUES
('2021-03-13 02:01:00', 'user 22', 72),
('2021-02-13 03:00:00', 'user 23', 33),
('2021-01-13 04:00:00', 'user 24', 15),
('2021-06-13 16:00:00', 'user 25', 122)
  • Проверить, что данные записались корректно, итого 4 строки:
select * from temp.test;
 
SELECT *
FROM temp.test
 
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-06-13 16:00:00 │ user 25 │       122 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-02-13 03:00:00 │ user 23 │        33 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-03-13 02:01:00 │ user 22 │        72 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-01-13 04:00:00 │ user 24 │        15 │
└─────────────────────┴─────────┴───────────┘
 
4 rows in set. Elapsed: 0.006 sec.

Вместе с созданием данных создаются партиции, которые хранятся в системной таблице system.parts.

  • Наконец, можно выполнить freeze для создания хардлинков, т.е. т.н. “бэкапов”:
alter table test freeze;

Проверить директорию shadow, в которой видно, что на каждую строку в таблице, добавленную ранее вручную, создана своя партиция в количестве 4 штук – наглядный принцип работы Clickhouse:

ll clickhouse/shadow/1/data/temp/test/
total 24
drwxr-x--- 6 clickhouse clickhouse 4096 Mar 17 10:26 ./
drwxr-x--- 3 clickhouse clickhouse 4096 Mar 17 10:26 ../
drwxr-x--- 2 clickhouse clickhouse 4096 Mar 17 10:26 1610499600_3_3_0/
drwxr-x--- 2 clickhouse clickhouse 4096 Mar 17 10:26 1613174400_2_2_0/
drwxr-x--- 2 clickhouse clickhouse 4096 Mar 17 10:26 1615590000_1_1_0/
drwxr-x--- 2 clickhouse clickhouse 4096 Mar 17 10:26 1623589200_4_4_0/
  • А также проверить, что все созданные хардлинки через freeze в директории shadow имеют права только на чтение:
ll clickhouse/shadow/1/data/temp/test/1610499600_3_3_0/
total 56
drwxr-x--- 2 clickhouse clickhouse 4096 Mar 17 10:26 ./
drwxr-x--- 6 clickhouse clickhouse 4096 Mar 17 10:26 ../
-r--r----- 3 clickhouse clickhouse  346 Mar 17 10:17 checksums.txt
-r--r----- 3 clickhouse clickhouse   88 Mar 17 10:17 columns.txt
-r--r----- 3 clickhouse clickhouse    1 Mar 17 10:17 count.txt
-r--r----- 3 clickhouse clickhouse   30 Mar 17 10:17 date.bin
-r--r----- 3 clickhouse clickhouse   48 Mar 17 10:17 date.mrk2
-r--r----- 3 clickhouse clickhouse    8 Mar 17 10:17 minmax_date.idx
-r--r----- 3 clickhouse clickhouse   30 Mar 17 10:17 pageviews.bin
-r--r----- 3 clickhouse clickhouse   48 Mar 17 10:17 pageviews.mrk2
-r--r----- 3 clickhouse clickhouse    4 Mar 17 10:17 partition.dat
-r--r----- 3 clickhouse clickhouse    8 Mar 17 10:17 primary.idx
-r--r----- 3 clickhouse clickhouse   34 Mar 17 10:17 user_id.bin
-r--r----- 3 clickhouse clickhouse   48 Mar 17 10:17 user_id.mrk2
  • Чтобы хардлинки превратились в более-менее полноценный бэкап, необходимо выполнить их копирование в отдельную директорию через cp -r или rsync с ключом –hard-links для создания хранимой копии. Обратить внимание, что копировать удобнее содержимое директории /clickhouse/shadow/1/data, отсекая лишние пути, т.к. в дальнейшем удобнее будет восстанавливать:
mkdir /tmp/backup_test
cp -r /clickhouse/shadow/1/data/temp/test/* /tmp/backup_test
  • Теперь, когда сделана копия таблицы test, необходимо её удалить и проверить восстановление. Но перед этим необходимо очистить директорию shadow для возможности создания последующих бэкапов:
rm -rf clickhouse/shadow/*
  • И дропнуть таблицу (убедившись, что все сделано корректно и для неё имеется бэкап):
drop table temp.test;
  • Теперь необходимо создать таблицу заново, чтобы подготовить её к восстановлению (удобно использовать уже имеющиеся sql в директории clickhouse/metadata):
CREATE TABLE IF NOT EXISTS temp.test
(
`date` Datetime,
`user_id` String,
`pageviews` Int32
)
ENGINE = MergeTree()
PARTITION BY toStartOfHour(date)
ORDER BY (date)
  • И скопировать все партиции из бэкапа по пути clickhouse/data/temp/test/detached, не забыв поправить права:
cp -r /tmp/backup_test/* /clickhouse/data/temp/test/detached
chown -R clickhouse. data/temp/test/detached/

Но на этом восстановление не закончено, а только начинается – партиции на месте, но они в состоянии detached, а потому каждую из них необходимо подключить явно. Ранее упоминалось, что есть системная таблица со списком всех партиций. Так вот есть аналогичная, где хранятся все подхватившиеся таблицы из бэкапа, но ещё не подключенные в состоянии detached. Поэтому необходимо проверить, что есть в этой таблице:

select database, table, name, partition_id from system.detached_parts
 
SELECT
    database,
    table,
    name,
    partition_id
FROM system.detached_parts
 
┌─database─┬─table─┬─name─────────────┬─partition_id─┐
│ temp     │ test  │ 1613174400_2_2_0 │ 1613174400   │
│ temp     │ test  │ 1610499600_3_3_0 │ 1610499600   │
│ temp     │ test  │ 1623589200_4_4_0 │ 1623589200   │
│ temp     │ test  │ 1615590000_1_1_0 │ 1615590000   │
└──────────┴───────┴──────────────────┴──────────────┘
  • Из вывода выше видно, что подтянулись все данные. Теперь их можно подключать, т.е “приатачить”, указав имя партиции из поля “partition_id”:
alter table test attach partition 1613174400;
alter table test attach partition 1610499600;
alter table test attach partition 1623589200;
alter table test attach partition 1615590000;
  • И финальная проверка, что данные вернулись на место:
select * from test;
 
SELECT *
FROM test
 
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-06-13 16:00:00 │ user 25 │       122 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-02-13 03:00:00 │ user 23 │        33 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-03-13 02:01:00 │ user 22 │        72 │
└─────────────────────┴─────────┴───────────┘
┌────────────────date─┬─user_id─┬─pageviews─┐
│ 2021-01-13 04:00:00 │ user 24 │        15 │
└─────────────────────┴─────────┴───────────┘

На этом демонстрационный процесс восстановления закончен. 

Автоматическое восстановление через clickhouse-backup

Исходя из всего проделанного выше может показаться, что будет крайне утомительно выполнять подобную операцию для больших объемов данных. А потому есть более автоматизированный способ с использованием сторонней утилиты clickhouse-backup. Но для его использования надо понимать, как работает процесс восстановления пошагово вручную.

Перед началом использования clickhouse-backup посмотреть на странице гитхаба ограничения, хотя в стандартных сценариях использования они не должны будут повлиять.

Никогда не меняйте права доступа к файлам в /var/lib/clickhouse/backup (или по пути /clickhouse/backup внутри контейнера в рамках данной статьи). Этот путь содержит жесткие ссылки. Права для всех жестких ссылок на одни и те же данные на диске всегда идентичны. Это означает, что если вы измените права доступа / владельца / атрибуты для жесткой ссылки в пути к резервной копии, то права на файлы, с которыми работает Clickhouse, также будут изменены. Это может привести к повреждению данных.

Установка

wget https://github.com/AlexAkulov/clickhouse-backup/releases/download/v0.6.4/clickhouse-backup.tar.gz
tar -xf clickhouse-backup.tar.gz
cp clickhouse-backup/clickhouse-backup /usr/local/bin/

Настройка

  • Конфиг по умолчанию можно получить командой ниже:
clickhouse-backup default-config
  • Но весь целиком он не нужен, поэтому нужно изменить лишь часть параметров, необходимых для работы. Для этого потребуется подготовить директорию и сам конфигурационный файл. В зависимости от используемых настроек, понадобится указать логин\пароль, хост, порт и путь до директории с кликхаусом (создавать на хост-машине, а не внутри контейнера – будьте внимательнее):
mkdir /etc/clickhouse-backup
cat > /etc/clickhouse-backup/config.yml << EOF
clickhouse:
  username: $SYSTEM_USER
  password: "$SYSTEM_USER_PASS"
  host: localhost
  port: 9000
  data_path: "$CLICKHOUSE_DIR/clickhouse"
EOF
  • Для проверки выполнить команду, которая выводит список таблиц из кликхауса. Если список есть, значит конфиг корректный. В противном случае стоит проверить, всё ли введено правильно, особенно логин\пароль и хост:
clickhouse-backup tables
temp.test

Создание резервной копии

  • Создание элементарно – можно выполнить команду без аргументов, а можно указать явное имя бэкапа:
BACKUP_NAME=test.bkp
clickhouse-backup create $BACKUP_NAME
 
2021/03/17 13:54:22 Create backup 'test.bkp'
2021/03/17 13:54:22 Freeze 'temp.test'
2021/03/17 13:54:22 Copy part hashes
2021/03/17 13:54:22 Writing part hashes
2021/03/17 13:54:22 Copy metadata
2021/03/17 13:54:22   Done.
2021/03/17 13:54:22 Move shadow
2021/03/17 13:54:22   Done.
  • Убедиться, что копия создалась:
clickhouse-backup list
Local backups:
- 'test.bkp'    (created at 17-03-2021 13:54:22)

Под капотом после создания выполняется следующее: из директории с данными кликхауса осуществляется копирование метаданных (т.е. schema) и непосредственно самих данных таблиц из директории shadow (по сути также, как было сделано в примере ранее вручную через freeze). И всё это складывается в директорию по пути /var/lib/clilckhouse/backup, где и хранятся все бэкапы.

Восстановление резервной копии

  • Теперь необходимо проверить, как работает восстановление. Предварительно необходимо удалить таблицу test:
drop table temp.test;
  • И выполнить восстановление одной командой:
clickhouse-backup restore test.bkp
2021/03/17 14:08:35 Create table 'temp.test'
2021/03/17 14:08:35 Prepare data for restoring 'temp.test'
2021/03/17 14:08:35 ALTER TABLE `temp`.`test` ATTACH PART '1610499600_2_2_0'
2021/03/17 14:08:35 ALTER TABLE `temp`.`test` ATTACH PART '1613174400_1_1_0'
2021/03/17 14:08:35 ALTER TABLE `temp`.`test` ATTACH PART '1615590000_4_4_0'
2021/03/17 14:08:35 ALTER TABLE `temp`.`test` ATTACH PART '1623589200_3_3_0'
  • Когда БД несколько, можно воспользоваться ключом и regex с явным указанием, в какую БД восстановить и какие таблицы. Например, все таблицы:
clickhouse-backup restore 'BKP_NAME' --table=DB_NAME.*

Также поддерживаются ключи  --schema и —data – первый восстанавливает только схему без данных, а второй – только данные, если схема уже есть.

Создание резервной копии по расписанию через crontab

Для создания копий с крона будет использоваться всё тот же clilckhouse-backup и скрипт:

DEST="/backup/"
DATA_DIR="/storage/clickhouse/backup"
BACKUP_NAME="clickhouse-`date +%F_%H_%M`"

clickhouse-backup create ${BACKUP_NAME}
 
tar cvfz ${DATA_DIR}/${BACKUP_NAME}.tar.gz ${DATA_DIR}/${BACKUP_NAME} 2>&1 >/dev/null
rm -rf ${DATA_DIR}/${BACKUP_NAME}
mv ${DATA_DIR}/${BACKUP_NAME}.tar.gz ${DEST}

Суть скрипта сводится к тому, чтобы:

  1. Сделать РК через clickhouse-backup
  2. Заархивировать РК, сжав в gzip
  3. И выполнить перемещение в директорию с бэкапами на локальном сервере

При добавлении скрипта в /etc/crontab, проверить, что в переменной PATH указан путь, где лежит бинарник clickhouse-backup, в противном случае скрипт выполнен не будет.

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

Заключение

В статье был рассмотрен максимально подробный процесс создания бэкапа Clickhouse и восстановления данных с использованием ручного и автоматизированного способа. СУБД и её администрирование на первый взгляд может показаться немного сложным для понимания, но это плата за преимущества (скорость). Во всём остальном проблем она не доставляет, а наоборот помогает решать задачи, связанные с хранением и выборкой огромнейших объемов данных.

Используемые источники

3 8 899 просмотров clickhouse
Понравилась статья? Поделиться с друзьями:
Вам также может быть интересно
Kubernetes 0 87 просмотров
Vector: отправка логов в Yandex SQS (AWS SQS)
Краткая заметка по настройке vector по передаче сообщений от k8s в yandex SQS
Администрирование 0 221 просмотров
Java Spring Boot: подключение в Kafka через TLS
Пример подключения к Kafka из приложения на Java Spring Boot через mTLS
Kubernetes 0 209 просмотров
Observability: eBPF, APM и OpenTelemetry
Пример настройки observability в кластере kubernetes
Linux 0 1 844 просмотров
SOPS + Age: Шифруем секреты
Это краткая напоминалка для шифрования YAML-файлов с секретами, которые публикуются в Git.
Linux 2 3 203 просмотров
Proxmox & packer: автоматизация подготовки VM
Пример использования Packer для создания шаблона Ubuntu в Proxmox 7
Linux 0 1 340 просмотров
Ubuntu: skip invalid certificate in APT
В корпоративной сети иногда бывают прокси-серверы, которые выступают в роли MITM, анализируя трафик. Для
Комментарии: 3
  1. Аркадий

    У меня не создается metadata при бекапе. В итоге не могу восстановить :sad:

    Ответить
    1. admin (автор)

      Посмотрите на гитхабе информацию, с момента написания статьи уже много времени прошло :)
      https://github.com/AlexAkulov/clickhouse-backup

      Ответить
      1. Аркадий

        Спасибо :smile:
        Обновил clickhouse-backup и все стало работать :idea:

        Ответить
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: