ClickHouse rezerves kopijas un atjaunošana: BACKUP, inkrementālās kopijas un S3 praksē

Strādājoša ClickHouse rezerves kopija ir tāda, kuru esat vismaz reizi atjaunojuši. ClickHouse ir iebūvētas BACKUP un RESTORE komandas, kas raksta uz lokālu disku, S3 vai Azure, atbalsta inkrementālās kopijas un darbojas fonā. Sākt ir vienkārši, un lielākā daļa īstā darba ir detaļās: kur kopijas glabājas, cik gara kļūst inkrementālo kopiju ķēde un vai atjaunošana iekļaujas jūsu atjaunošanas logā.

Pirmo punktu komandas izlaiž visbiežāk. ClickHouse dokumentācijā tas pateikts tieši: replikācija pasargā no aparatūras kļūmēm, bet nepasargā no cilvēku kļūdām, un daudzos gadījumos šādas kļūdas skar visas replikas. Nepareizs ALTER ... DELETE, DROP nepareizajā klasterī vai slikta migrācija tiek replicēta tikpat uzticami kā labs ieraksts.

1. solis: dodiet ClickHouse vietu, kur rakstīt kopijas

Lokālam vai piemontētam mērķim definējiet disku un atļaujiet to rezerves kopijām. Šī ir konfigurācija no oficiālā ceļveža, un tai vajadzīgs servera restarts:

<!-- /etc/clickhouse-server/config.d/backup_disk.xml, pēc tam restarts -->
<clickhouse>
    <storage_configuration>
        <disks>
            <backups>
                <type>local</type>
                <path>/backups/</path>
            </backups>
        </disks>
    </storage_configuration>
    <backups>
        <allowed_disk>backups</allowed_disk>
        <allowed_path>/backups/</allowed_path>
    </backups>
</clickhouse>

S3 gadījumā disks vispār nav vajadzīgs: S3() mērķis pieņem galapunktu un ceļu, piekļuves atslēgu un noslēpumu tieši komandā. Azure Blob Storage darbojas tāpat ar AzureBlobStorage(). Lokāls disks tajā pašā serverī ir tikai starpposms; kopija, kas atrodas uz tās pašas mašīnas, kuru tā aizsargā, nav rezerves kopija.

2. solis: izveidojiet pilnu kopiju un sekojiet tai

-- pilna vienas datubāzes rezerves kopija fonā
BACKUP DATABASE analytics
TO S3('https://s3.eu-central-1.amazonaws.com/acme-ch-backups/analytics/2026-11-12-full',
      '<key id>', '<secret>')
ASYNC;

-- atgriež id; sekojiet tam
SELECT id, name, status, num_files, uncompressed_size, compressed_size, error
FROM system.backups
ORDER BY start_time DESC
LIMIT 5;

Bez ASYNC komanda bloķējas, līdz kopija ir pabeigta, kas lielā datubāzē nozīmē klienta sesiju, kurai jāpaliek atvērtai stundām. Ar ASYNC tā uzreiz atgriež id. Tabulā system.backups statuss mainās no CREATING_BACKUP uz BACKUP_CREATED vai uz BACKUP_FAILED ar iemeslu kolonnā error. Atjaunošana ziņo RESTORING, RESTORED vai RESTORE_FAILED. Katra operācija tiek ierakstīta arī system.backup_log, un uz to jāreaģē jūsu monitoringam.

Var dublēt vienu tabulu, datubāzi vai ALL ar izņēmumiem, un sintakse atbalsta EXCEPT TABLES un EXCEPT DATA FROM TABLES, lai saglabātu definīciju bez rindām, piemēram, lielām starptabulām, kuras var izveidot no jauna.

3. solis: inkrementālās kopijas ar base_backup

Daudzterabaitu datubāzes pilna kopija prasa laiku un vietu, tāpēc parasti izmanto periodisku pilnu kopiju un inkrementālās kopijas. Inkrementālā kopija glabā tikai to, kas mainījies kopš kopijas, kas norādīta base_backup:

BACKUP DATABASE analytics
TO S3('https://s3.../analytics/2026-11-13-incr', '<key id>', '<secret>')
SETTINGS base_backup = S3('https://s3.../analytics/2026-11-12-full',
                          '<key id>', '<secret>')
ASYNC;

Āķis ir dokumentācijā: lai atjaunotu inkrementālo kopiju, vajadzīgas visas kopijas, uz kurām tā balstās. Ja kāds pievieno S3 dzīves cikla noteikumu, kas pēc 30 dienām dzēš pilno kopiju, katra uz to balstītā inkrementālā kopija kļūst nelietojama. Turiet ķēdi īsu, regulāri sāciet jaunu pilnu kopiju un ļaujiet glabāšanas politikai dzēst veselas ķēdes, nekad atsevišķus posmus.

4. solis: atjaunošana, kas ir galvenais

-- atjaunojiet blakus oriģinālam, nekad pāri tam
RESTORE TABLE analytics.events AS analytics.events_restored
FROM S3('https://s3.../analytics/2026-11-13-incr', '<key id>', '<secret>');

-- tikai shēma, piem., lai atjaunotu tukšu struktūru
RESTORE DATABASE analytics FROM Disk('backups', 'analytics-full.zip')
SETTINGS structure_only = 1;

Atjaunošana ar jaunu nosaukumu ļauj pēc sliktas dzēšanas atgūt dažas partīcijas, neaiztiekot dzīvo tabulu. Ja atgūstaties pēc nejaušas masveida dzēšanas, mūsu piezīmes par rindu dzēšanu ClickHouse paskaidro, kāpēc vieglā dzēšana un mutāciju dzēšana uzvedas atšķirīgi, un tas ir svarīgi, izlemjot, ko kopēt atpakaļ. Iestatījumi, piemēram, restore_table_data un restore_access_entities, nosaka, ko atjaunošana atgriež; lietotāji, lomas un kvotas tiek iekļauti tikai tad, ja tie izveidoti ar SQL, nevis definēti users.xml.

Klasteri, vienlaicīgums un alternatīvas

• ON CLUSTER izpilda kopēšanu vai atjaunošanu visā klasterī. To koordinē Keeper, tāpēc Keeper vai mezgla problēma ilgas kopēšanas laikā ir kļūmes scenārijs, kas jāplāno.
• Vienlaicīgums. allow_concurrent_backups un allow_concurrent_restores pēc noklusējuma ir true. Iestatiet tos uz false sadaļā <backups>, ja vēlaties tikai vienu operāciju klasterī vienlaikus.
• ALTER TABLE ... FREEZE izveido cietās saites mapē /var/lib/clickhouse/shadow/, kas veciem datiem aizņem maz vietas. Dokumentācijā norādīts, ka serveris šīs kopijas nepārvalda un tās atrodas uz tās pašas aparatūras, tāpēc tās jānosūta citur. Trešās puses rīks clickhouse-backup automatizē šo pieeju un joprojām ir izplatīts vecākās sistēmās.
• Failu sistēmas momentuzņēmumus (piemēram, ZFS) dokumentācija iesaka veidot uz atsevišķām replikām, kas izslēgtas no vaicājumu trafika, nevis uz mezgliem, kas apkalpo dzīvus vaicājumus.

Kas mainās daudzterabaitu datiem

• Mēriet atjaunošanas laiku, nevis kopēšanas laiku. Jūsu atjaunošanas laiks ir tas, cik ilgi aizņem nolasīt no S3 pilno kopiju un visas inkrementālās kopijas un ierakstīt tās atpakaļ. Mēriet to rezerves klasterī pilnā izmērā; dokumentācija iesaka regulāri praktizēt atjaunošanu rezerves klasterī. Mūsu rezerves kopiju atjaunošanas testēšanas ceļvedis apraksta, kā to padarīt par rutīnu.
• Aizsargājiet produkciju kopēšanas laikā. max_backup_bandwidth (pēc noklusējuma 0, neierobežots) ierobežo lasīšanas ātrumu vienai kopijai, un backup_threads ierobežo paralēlismu. Pilna kopija pilnā ātrumā konkurē ar apvienošanu (merges) un vaicājumiem par disku un tīklu.
• Glabāšanas klases izmaksas. s3_storage_class nosaka klasi kopiju objektiem. Aukstākas klases ir lētākas, bet var padarīt atjaunošanu lēnāku vai dārgāku; pārbaudiet to pirms incidenta, nevis tā laikā.
• 50 GB drošības tīkls. Pēc noklusējuma max_table_size_to_drop un max_partition_size_to_drop ir 50 GB: ClickHouse atsakās izpildīt DROP TABLE, TRUNCATE vai DROP PARTITION virs šī izmēra. Neiestatiet tos uz 0, lai skripti izietu cauri. Lielām tabulām šī pārbaude bieži ir pēdējais, kas stāv starp drukas kļūdu un pilnu atjaunošanu.
• Turiet akreditācijas datus ārpus skriptiem. S3 atslēgas, kas ierakstītas BACKUP komandās, nonāk čaulas vēsturē un uzdevumu definīcijās. Izmantojiet ierobežotu IAM lietotāju ar piekļuvi tikai kopiju kausam un turiet kausu atsevišķā kontā vai ar object lock, ja vajadzīga aizsardzība pret kompromitētu serveri.