ClickHouse 26.8 LTS'ye 26.3'ten geçiş yapılan yükseltme 57 kırıcı değişiklik içeriyor

ClickHouse 26.8 LTS sürümünü duyurdu ve upstream changelog üzerinden yapılan bir dev.to analizine göre, önceki uzun vadeli destek sürümü 26.3'ten yükseltme yapmak, tek bir sürümdeki değil, beş sürüme yayılmış 57 benzersiz kırıcı değişikliği özümsemek anlamına geliyor.

Yazıda açıklanan temel sorun şu: LTS'den LTS'ye geçiş asla tek adımlık bir hamle değildir. 26.3'ten 26.8'e giden yol 26.4, 26.5, 26.6 ve 26.7'den geçiyor ve bu ara sürümlerdeki her geriye dönük uyumsuz değişiklik de geçerli oluyor. En riskli kalemlerden bazıları 26.8 notlarında hiç提及 edilmiyor.

Atlamanın arka lanındaki sayılar

dev.to sayımına göre ara sürümler sırasıyla 6, 10, 10 ve 11 kırıcı değişiklik içeriyor; 26.8'in kendisi ise 21 girdiyle en yüksek tekil sayıyı listeliyor. Aynı sürümler yaklaşık 199 yeni özellik ve 416 performans iyileştirmesi de getiriyor.

Upstream changelog aslında beş sürüm boyunca 58 geriye dönük uyumsuz girdi listeliyor, ancak PR #103285'teki http_max_fields azaltımı bir backport üzerinden hem 26.4 hem de 26.5 bölümlerinde yer aldığı için benzersiz değişiklik sayısı 57'de kalıyor. Yazar bazı uyarılar ekliyor: 26.8'in 21 girdisinden üçü hâlâ çözülmemiş TODO işaretleri taşıyor, biri revert-of-revert olarak işaretlenmiş durumda ve 26.8 bölümü hâlä devam ediyor olarak işaretli, yani sayı henüz değişebilir. Tüm rakamlar 27 Ağustos 2026'da sayılmıştır.

Resmi listenin ötesinde, beş sürüm boyunca yaklaşık 70 ayar varsayılan değerlerini değiştirdi. Bu girdiler geriye dönük uyumsuzluk başlığı altında hiç görünmüyor, ancak yazıya göre pratikte beklenmedik davranışların önemli bir kısmından bunlar sorumlu.

Henüz tam olarak yayınlanmadı

27 Ağustos 2026 itibarıyla 26.8 duyurulmuştu ama tam olarak yayınlanmamıştı: release branch kesilmiş ve v26.8.1.1-lts olarak sürümlenmişti, ancak tag ve Docker imajları yayınlanmamıştı. Yazar, kesin cevap için ClickHouse'un version_date.tsv dosyasını sorgulamayı öneriyor ve Docker Official Images'ın GitHub tag'lerinin birkaç patch sürümü gerisinde kaldığı konusunda uyarıyor: 26.3.24.4 çoktan yayınlanmış olmasına rağmen clickhouse:lts tag'i hâlâ 26.3.20.7'ye çözümleniyordu.

Geçmişte LTS sürümleri hızla patch biriktiriyor (26.7 bir ay içinde beş patch gördü), bu yüzden yazı üretim kümelerini yükseltmeden önce yaklaşık 26.8.3'e kadar beklemeyi ve bu arayı hazırlık için kullanmayı öneriyor.

Yükseltmeyi engelleyebilecek üç değişiklik

Analiz, yükseltmeyi tamamen durdurabilecek üç kalem öne çıkarıyor:

Birincisi, 26.6'dan itibaren varsayılan x86 build'i x86-64-v3'ü hedefliyor ve AVX2 ile ilgili instruction set'leri gerektiriyor; fiilen Intel Haswell veya daha yenisi ile AMD Excavator veya daha yenisi demek bu. 2015 sonrası neredeyse her x86 CPU uygundur, ancak eski makinelerde veya CPU flag'lerini maskeleyen hypervisor'lerde binary çalışmayı reddedecektir; bir amd64compat build'i yedek olarak düz x86-64'ü hedefler. Bu değişiklik 26.8 notlarında yer almıyor, bu yüzden gözden kaçması kolay.

İkincisi, insert_deduplication_version zorunlu bir geçiş sırasına sahip. Bir config onu old_separate_hashes veya compatible_double_hashes olarak ayarlıysa, 26.7 veya sonrası bir sunucu doğrudan başlamayı reddeder. Geçiş, ayarı kaldırmadan önce hem eski hem de birleşik hash'leri yazan bir sürümün deduplication penceresi boyunca (replicated tablolar için varsayılan olarak bir saat, non-replicated olanlar için eşdeğer insert sayısı) çalıştırılmasını gerektiriyor. Ayrıca 26.6, deduplication'ın bütün insert edilen block'lar üzerinde çalışacak şekilde yeniden tanımladı; farklı insert'lerin ürettiği özdeş part'lar veya aynı satırların yeniden sıralanmış insert'leri artık çapraz deduplicate edilmiyor.

Üçüncüsü ve yazarın görüşüne göre ekipleri en çok zorlayacak olan: 26.7'den itibaren kullanıcı SQL'inden kaynaklanan S3 erişimi, sunucunun kendi cloud kimlik bilgilerini varsayılan olarak artık çözmüyor; ister ortam değişkenlerinden, IMDS veya IRSA'dan, instance profile'lardan, AWS config dosyalarından, role tabanlı STS'den veya GCP OAuth metadata'sından gelsin. Önceki davranışı geri getirmek için hem use_environment_credentials hem de s3_load_table_anonymously_if_credentials_restricted değil, s3_allow_server_credentials_in_user_queries 1'e ayarlanmalı. Asıl çetrefil kısım başlangıç yolu: s3_load_table_anonymously_if_credentials_restricted varsayılan olarak açıkken, kalıcı S3 tabloları, S3Queue tabloları, dinamik S3 diskleri ve etkilenen DataLakeCatalog'lar başlangıcı durdurmak yerine anonim olarak yükleniyor; böylece sunucu sağlıklı görünüyor ve yalnızca okuma anında başarısız oluyor.

Sorgu sonuçlarındaki sessiz değişiklikler

İki 26.5 değişikliği hata fırlatmadan sonuçları değiştiriyor. Date parsing varsayılanları (date_time_input_format ve cast_string_to_date_time_mode) basic'ten best_effort'a taşındı; böylece 'Apr 15, 2020 10:30:00' gibi gevşek string'ler artık reddedilmek yerine parse ediliyor ve hatalı girdi geri sekmek yerine içeri giriyor. Ve açık bir time zone belirtilmeden DateTime veya DateTime64'e yapılan CAST artık kaynak argümanın time zone'unu koruyor, bu da mevcut sorgularda görüntülenen timestamp'leri değiştiriyor.

Neden önemli

LTS sürümleri üretim kullanıcılarının standartlaştığı şeydir ve ClickHouse'un sürüm temposu, her LTS atlamasının CPU gereksinimleri ve hedef sürümün kendi notlarında hiç görünmeyen başlangıç reddileri dahil beş sürümlük kırılımı sessizce paketlediği anlamına geliyor. Buradaki en tehlikeli değişiklikler sessiz olanlar: anonim olarak yüklenen ve yalnızca okuma anında başarısız olan S3 tabloları ve eskiden reddettiği verileri kabul eden parsing. 26.3'teki ekipler şimdi CPU flag'lerini, deduplication ayarlarını ve her S3 kimlik bilgisi yolunu denetlemeli ve varsayılan değer değişikliklerini dipnot değil, kırıcı değişiklik yüzeyinin bir parçası olarak görmeli.