ClickHouse restore planı tablo boyutuyla başlar
ClickHouse çoğu zaman yüksek hacimli analitik veri tutar. Bu nedenle backup/restore planı küçük OLTP veritabanı gibi düşünülmemelidir. Birkaç yüz gigabaytlık tablo ile onlarca terabaytlık tablo aynı geri dönüş davranışına sahip değildir.
İlk soru şudur: Hangi veriyi mutlaka geri döndürmek zorundayız, hangi veri yeniden üretilebilir? Ham eventler başka bir kuyrukta veya obje deposunda duruyorsa bazı tablolar yeniden oluşturulabilir. Ama tek kopya ClickHouse ise yedek kritik hale gelir.
- En büyük tablolar ve partition dağılımı düzenli izlenmelidir.
- Restore süresi veri boyutu kadar ağ ve object storage hızına da bağlıdır.
- Materialized view ve özet tabloların yeniden üretilebilir olup olmadığı bilinmelidir.
- TTL veya partition silme kararından önce geri dönüş ihtiyacı konuşulmalıdır.
Partition bazlı düşünmek işleri sadeleştirir
ClickHouse tabloları çoğunlukla tarih veya tenant bazlı partition mantığıyla büyür. Bir olay yalnızca son günün verisini etkilediyse tüm tabloyu geri döndürmek gerekmeyebilir. Partition bazlı doğrulama hem süreyi hem riski azaltır.
Yine de partition silme ve geri yükleme komutları üretimde dikkat ister. Yanlış partition adı, yanlış tablo veya eksik doğrulama analitik raporları bozabilir.
Partition ve satır dağılımını okuma
select database, table, partition, sum(rows) as rows, formatReadableSize(sum(bytes_on_disk)) as size from system.parts where active group by database, table, partition order by sum(bytes_on_disk) desc limit 20;
Restore doğrulaması rapor sorusuyla yapılır
ClickHouse restore sonrası sadece tablo açıldı mı diye bakmak yeterli değildir. Kullanıcının baktığı pano, funnel, günlük gelir veya kullanım raporu hangi sorguya dayanıyorsa o sorgular restore hedefinde çalıştırılmalıdır.
Analitik veride küçük fark bazen kabul edilebilir, bazen edilemez. Reklam tıklaması raporunda yüzde küçük sapma tolere edilebilirken fatura metriklerinde aynı sapma sorun olabilir.
Restore sonrası rapor kontrol notu
Kontrol edilen tablo: Partition: Beklenen satır aralığı: Restore sonrası satır: Kontrol edilen rapor sorgusu: Kabul edilebilir fark: Karar: geçer / eksik / yeniden dene
Yedek maliyeti de planın parçasıdır
ClickHouse’ta yedek maliyeti yalnızca depolama değildir. Ağ çıkışı, object storage istekleri, restore için geçici disk, mühendislik zamanı ve rapor kesintisi de maliyete dahil olur.
Bu yüzden saklama süresi, TTL ve backup politikası birlikte tasarlanmalıdır. Her şeyi sonsuza kadar tutmak pahalıdır; erken silmek ise olay anında çaresiz bırakır.