3.0 Sürümüne Yükseltme

GoArchive 3.0, önceki sürümlerin takip tablolarını okumaz ve taşımaz (migrate); yapılandırma dosyasını da katı kurallarla (strict) okur. Yükseltmeyi kısa bir bakım adımı olarak planlayın: Çalışan görevleri mevcut sürümünüzle tamamlayın, ardından yeni sürüme geçin.

Kısa Özet #

1. Her görevi mevcut sürümünüzle tamamlayın, ardından görevin takip tablolarını silin (2.x Sürümünden Geçiş ). GoArchive 3.0 bu tabloları hiçbir zaman okumaz ve taşımaz.
2. Yapılandırmayı yeniden yazın: Her görev job_type gerektirir, verification tek bir değer alır ve tanımlanmamış anahtarlar reddedilir (Yapılandırma Değişiklikleri ).
3. TRIGGER yetkisini görev tablolarında doğrudan kullanıcıya verin: Arşivleme ve kalıcı silme (purge) görevleri için kaynakta, arşivleme ve salt kopyalama (copy-only) görevleri için hedefte. 2.x sürümündeki hazır yetki tanımlarında bu yetki yer almaz ve ön kontroller (preflight checks) bu yetki olmadan görevi reddeder (Kullanıcı Yetkileri ).
4. Betiklerinizden --force ve --skip-verify parametrelerini kaldırın, --skip-validate-preflight parametresini yeni adıyla değiştirin ve betiklerin çıkış kodlarını nasıl okuduğunu kontrol edin (Komut Satırı Değişiklikleri ).
5. goarchive validate komutunu çalıştırın. 3.0 sürümündeki ön kontroller, anahtarları ve ilişkileri 2.x sürümüne göre daha sıkı denetler.

2.x biçimindeki bir yapılandırma dosyası yüklenmez; verilen hata mesajı sizi yükseltme rehberine yönlendirir. 2.x takip tabloları ise çalıştırma başlangıcında reddedilir.

2.x Sürümünden Geçiş #

3.0 sürümündeki takip tabloları tamamen yenilenmiştir: Her görev için tipe özel bir günlük tablosu (typed log) ve görev bağlama bilgisi (job binding) kullanılır; eski tip kontrol noktası (checkpoint) tablosu bulunmaz (Takip Tabloları ). Önceki bir sürümün oluşturduğu takip şeması reddedilir ve hiçbir kayıt taşınmaz.

1. Her görevi mevcut sürümünüzle tamamlayın. Böylece bekleyen (pending) veya kopyalanmış (copied) durumda hiçbir günlük satırı kalmaz. Tamamlayamadığınız bir görevi, kullandığınız sürümün dokümantasyonunda açıklandığı şekilde tamamen kullanımdan kaldırın (retire).

2. Takip şemasını kullanan tüm GoArchive süreçlerini durdurun.

3. Eski takip tablolarını silin. Bu işlemi job_schema içinde bir DBA olarak yapın; GoArchive’ın kendi kullanıcısında DROP yetkisi bulunmaz.

   -- Her günlük tablosu için DROP ifadelerini üretin (goarchive yerine kendi job_schema
   -- adınızı yazın), ifadeleri gözden geçirin ve çalıştırın.
   SELECT CONCAT('DROP TABLE `', table_schema, '`.`', table_name, '`;')
   FROM information_schema.tables
   WHERE table_schema = 'goarchive' AND table_name LIKE 'archiver_job_log%';
   
   DROP TABLE goarchive.archiver_job;
   DROP TABLE goarchive.goarchive_meta;
   

   Arşivlenen verilere ait kayıtlar uyumluluk (compliance) açısından değer taşıyorsa, eski günlükleri önce dışa aktarın. Alternatif olarak destination.job_schema ayarını yeni ve boş bir şemaya yönlendirebilirsiniz.

4. 3.0 sürümünü çalıştırın. İlk çalıştırma şemayı etiketler ve her görevi sıfırdan kaydeder. Her çalıştırma, görevin where aralığının başından başlar. Arşivleme ve kalıcı silme görevlerinde daha önce işlenmiş satırlar artık kaynakta bulunmaz. Salt kopyalama görevi ise tüm verileri yeniden kopyalar. Bu nedenle bu görevi boş bir hedefe yönlendirin ya da önceki sürümün kopyaladığı verilerden sonra başlayan bir where koşulu tanımlayın.

2.x Sürümüne Göre Diğer Yenilikler #

• Hedef tablolar InnoDB olmalıdır. archive ve copy-only, başka bir depolama motoru kullanan hedef tabloyu reddeder; validate ve dry-run bu durumu raporlar. Kolonları kaynaktan farklı sırada olan bir hedef ise kabul edilir ve her tablo için bir uyarı yazdırılır.
• Arşiv kurtarma, silmeden önce hedefi kontrol eder. Bir çalıştırma yarıda kalan işi sürdürürken, günlüğe kaydedilmiş bir kök kayda ait her satırın silme başlamadan önce hedefte bulunması gerekir. Aksi halde çalıştırma durur ve hiçbir şey silmez. Kurtarma işlemi verification: none ayarında bile hedefi okur; bu nedenle arşivleme kullanıcısının hedef tablolarda SELECT yetkisine ihtiyacı vardır. Ayrıca bir arşivleme görevi, günlüğünde kopyalanmış kök kayıtlar bulunduğu sürece hedef veritabanına bağlı kalır.
• Büyük satırlar da kopyalanır. GoArchive, bağlanırken her sunucunun max_allowed_packet değerini okur. Yalnızca hedefin paket boyutundan büyük tek bir değer ya da nadiren bir INSERT ifadesinin tamamı yığını başarısız kılar. Bu durumda verilen hata, ilgili tabloyu ve çözüm yolunu belirtir.
• TRIGGER yetkisi sistem tarafından kanıtlanabilir olmalıdır. Bu yetki, her görev tablosunda doğrudan kullanıcıya verilmelidir. Yalnızca bir rol (role) üzerinden gelen TRIGGER yetkisi reddedilir. --force-triggers parametresi bu kontrolleri kapsamaz.
• Kendine başvuran (self-referencing) ON DELETE CASCADE veya SET NULL tanımı içeren görev tabloları, arşivleme ve kalıcı silme görevlerinde reddedilir. Bunun nedeni, bir yığın satırının silinmesinin aynı tablodaki yığın dışı satırları değiştirecek olmasıdır.
• Desteklenmeyen bir karakter setindeki görev kolonu reddedilir. Her oturum utf8mb4 ile çalışır. Ön kontroller, karakter seti bu oturumda birebir korunamayan kolonları reddeder (Karakter Setleri ).
• Yarım kalmış işi bulunan durdurulmuş bir görev, ilişkili tablolarını diğer işlemler için rezerve tutar (işleme kapatır). Aynı kaynak veriler üzerinde çalışan ve ilişki ağacı bu tablolardan birini paylaşan başka bir görev, durdurulan görevin bir sonraki çalıştırması işini tamamlayana kadar reddedilir (Eşzamanlılık ve Kilitleme ).
• Çıktı ve çıkış kodları: Bir çalıştırma, raporunu yalnızca --progress ile stdout’a yazar; uyarılar stderr’e gider. Çıkış kodu; bir durdurmayı (3) ve başka bir canlı çalıştırmanın tuttuğu işi (4) başarısızlıktan (1) ayırt eder (Çıktı, İlerleme ve Çıkış Kodları ).
• Çalıştırma öncesi uyarılar: verification: count veya verification: none kullanıldığında bir uyarı yazdırılır; bu modlardan birinde JSON kolonları kullanılıyorsa ayrıca bir JSON uyarısı yazdırılır. Çünkü bu modlar kopyalanan satır değerlerini karşılaştırmaz.
• Konteyner imajı root olarak değil, /work dizininden UID 65532 kullanıcısıyla çalışır. /root/ altına bağlanan bir yapılandırma dosyası artık okunamaz; dosyayı /work/ altına bağlayın (Kurulum ).
• Günlük dosyaları Unix sistemlerde yalnızca sahibi tarafından okunabilir (0600) olarak oluşturulur. Bir çalıştırmanın günlüğü, çalıştırmanın nasıl sonlandığını sayılarıyla birlikte bildiren tek bir kayıtla biter.

Yapılandırma Değişiklikleri #

Yapılandırma dosyası katı kurallarla okunur (Yapılandırma ).

• Her görev job_type gerektirir: archive, purge veya copy-only. Görev yalnızca bu komutla çalışır.

• primary_key, foreign_key ve references bileşik anahtarlar (composite key) için liste olabilir. primary_key, tablonun PRIMARY KEY kolonlarını anahtar sırasıyla ve eksiksiz belirtmelidir. references ebeveyn tablonun anahtar kolonlarını belirtir ve foreign_key ile konum sırasına göre eşleşir. references yalnızca ebeveyn anahtarı tek kolondan oluşuyorsa belirtilmeyebilir.

• verification tek bir değer alır: sha256 (varsayılan), count veya none. Bu değer genel düzeyde ya da görev bazında tanımlanır. 2.x sürümündeki blok (method, skip_verification) reddedilir:

  2.x	3.0
  method: count	verification: count
  method: sha256	verification: sha256 (varsayılan)
  skip_verification: true	verification: none

• Her görev türü yalnızca kullandığı ayarları kabul eder. verification içeren bir purge görevi ya da batch_delete_size veya delete_sleep_seconds içeren bir copy-only görevi reddedilir. resume yalnızca copy-only görevlerine ait bir ayardır.

• Tanımlanmamış anahtarlar reddedilir. Anahtar adları birebir ve küçük harfle yazılmalıdır: Root_Table reddedilir. x-defaults: gibi yardımcı anahtarlar da reddedilir. Bu nedenle birleştirme anahtarlarının (merge keys) paylaştığı bir YAML çapası (anchor), bilinen bir anahtarın (örneğin gerçek bir görevin) altında tanımlanmalıdır.

• Görev adlarında büyük-küçük harf korunur. Komut satırındaki ad, dosyadaki adla birebir eşleşmelidir. Yalnızca harf büyüklüğüyle ayrışan iki ad reddedilir. Görev adları boşluk içermeyen, yazdırılabilir ASCII karakterlerden oluşmalı, - ile başlamamalı ve en fazla 255 karakter uzunluğunda olmalıdır.

• Bir tablo, bir görevde yalnızca bir kez yer alabilir.

• Dosya başına tek YAML belgesi: --- sonrasındaki ikinci bir belge yok sayılmaz, reddedilir.

• 2.0 sürümünün replika anahtarları reddedilir:

  2.0	3.0
  replica: (tek sunucu)	replication.servers: (liste)
  replica.host / port / user / password	replication.servers[].host / port / user / password
  replica.replication_channel: "billing"	replication.servers[].channels: ["billing"]
  replica.replication_channel: ""	replication.servers[].channels: [""], yalnızca varsayılan kanal; belirtilmezse veya [] verilirse tüm kanallar kontrol edilir
  safety.lag_threshold	replication.seconds_behind_source_within
  safety.check_interval	replication.check_interval

• Yeni günlük dosyası, Unix sistemlerde yalnızca sahibi tarafından okunabilir (0600; 2.x bu dosyayı 0644 ile oluşturuyordu). Windows’ta dosya, bulunduğu klasörün izinlerini devralır. Mevcut bir dosya kendi modunu korur.

Komut Satırı Değişiklikleri #

Kaldırılan veya Değişen Sınırlar #

2.2 Öncesi Bir Sürümden Geçiş #

GoArchive 3.0, 2.0 ile 2.2 arasındaki sürümlerin getirdiği değişiklikleri korur. Ara sürümleri atlayarak doğrudan yükseltme yapıyorsanız aşağıdaki değişiklikleri de göz önünde bulundurun:

• Yetkiler doğrulanabilir/kanıtlanabilir (provable) olmalıdır: Her yetki doğrudan kullanıcıya verilmelidir. Arşivleme ve kalıcı silme görevleri için kaynakta PROCESS yetkisi de gerekir (Kullanıcı Yetkileri ).

• Oturumlar UTC ile çalışır: where koşulu bir UTC oturumunda çalıştırılır. Bu nedenle NOW() ile karşılaştırılan bir DATETIME kolonu, yalın bir sabit değerle (literal) karşılaştırılan bir TIMESTAMP kolonu ve CURDATE() sınırları, sunucunun saat dilimine göre değil UTC’ye göre belirlenir. last_heartbeat_at değeri de UTC’dir: Bu değerin ne kadar eski olduğunu UTC_TIMESTAMP() ile ölçün.

• 2.2 öncesinde arşivlenen TIMESTAMP değerleri hatalı olabilir. Bu durum, kaynak ve hedef oturumları farklı saat dilimlerinde çalıştığında ortaya çıkar: Her kopyalama kaynağın yerel saat (wall-clock) metnini almış, hedef ise bu metni kendi saat diliminde okumuştur. Bir DBA bu değerleri yalnızca bir kez düzeltebilir:

  -- 1. Tabloyu yedekleyin.
  -- 2. Sıfırdan farklı bir sayı, bir saat dilimi adının tanınmadığını ve UPDATE işleminin
  --    kolonu NULL yapacağını gösterir: Durun.
  SET time_zone = '+00:00';
  SELECT COUNT(*) FROM archive.orders
   WHERE <only rows archived before 2.2>
     AND ts IS NOT NULL
     AND CONVERT_TZ(CONVERT_TZ(ts, '+00:00', '<zone the old DESTINATION sessions used>'),
                    '<zone the old SOURCE sessions used>', '+00:00') IS NULL;
  
  -- 3. Düzeltin; her kolon için yalnızca bir kez.
  UPDATE archive.orders
     SET ts = CONVERT_TZ(CONVERT_TZ(ts, '+00:00', '<zone the old DESTINATION sessions used>'),
                         '<zone the old SOURCE sessions used>', '+00:00')
   WHERE <only rows archived before 2.2>;
  

  Saat dilimlerini eski oturumların gördüğü şekliyle yazın (SYSTEM, sunucunun işletim sistemi saat dilimini ifade eder). İkinci bir çalıştırma değerleri yeniden bozar. Yaz saatinden kış saatine geçişte geri alınan saate denk gelen değerler kurtarılamaz.