Sınırlar ve Kısıtlamalar

GoArchive, soğuk veri (cold data), yani uygulama tarafından artık güncellenmeyen ve değiştirilmeyen durağan veriler için tasarlanmıştır. Sık güncellenen ve aktif olarak değişen sıcak (hot) veriler için tasarlanmamıştır.

Kesin Kısıtlamalar #

Bu kısıtlamaları ihlal eden görevler, çalıştırma başlamadan önce bağlantı aşamasında veya ön kontrollerde (preflight checks) reddedilir. Çalıştırma sözleşmesi ve JSON değerleri bu kuralın dışındadır; bunlar denetlenmez. Depolanmış zamansal anahtar değerleri ise karşılaşıldıkları anda, herhangi bir silme işleminden önce reddedilir.

Birincil Anahtarlar #

Göreve katılan her tablonun tek kolonlu veya bileşik (composite) bir PRIMARY KEY tanımı olmalıdır. Yapılandırmadaki primary_key değeri tam olarak bu kolonları, anahtardaki sıralarıyla belirtmelidir. FLOAT/DOUBLE, ENUM/SET, BIT ve izin verilen tipler listesi dışındaki diğer tüm tipler ile önek (prefix) anahtar parçaları anahtar olarak reddedilir. Kök tablonun anahtar tanımı, görev oluşturulurken kullanılan tanımla aynı kalmalıdır; değiştirilmiş bir tanım başlangıçta reddedilir.

Zamansal Değerler ve Satır Tanımlayıcıları (Identities) #

DATE, DATETIME ve TIMESTAMP anahtar değerleri geçerli olmalıdır: Değer, yılı 0001–9999 aralığında olan ve takvimde gerçekten var olan bir günü gösteren YYYY-MM-DD biçiminde yazılmalıdır. DATETIME ve TIMESTAMP değerlerinde buna ek olarak HH:MM:SS ve 0–6 kesirli basamak bulunur. Sıfır tarihler (zero dates), geçersiz saat değerleri, saat dilimi ekleri ve artık saniyeler (leap seconds), sunucunun SQL modlarından bağımsız olarak TEMPORAL_READ_CONTRACT ile reddedilir; bu kuralı aşan hiçbir geçersiz kılma (override) seçeneği yoktur. Anahtar olmayan zamansal değerler ise SQL metni olarak kopyalanır ve hiçbir zaman normalleştirilmez.

Çalıştırma Sırasında DDL ve Eşzamanlı Yazma Yapılmamalıdır (Sözleşme) #

GoArchive’ın doğru çalışması aşağıdaki çalıştırma sözleşmelerine dayanır. Kurtarma sürecinin durmasına yol açan durumlar hariç, kural ihlalleri sistem tarafından önceden denetlenmez; yalnızca dokümante edilir:

1. Görev çalışırken göreve katılan tablolarda DDL çalıştırılmamalıdır. Kolon listeleri başlangıçta bir kez okunur. Yeniden adlandırılan veya kaldırılan bir kolon, arşivleme ya da salt kopyalama yığınını kopya commit edilmeden önce başarısız kılar. Eklenen bir kolon ise tespit edilmez ve kopyalanmaz. Şema değişikliklerini çalıştırmalar arasında yapın.
2. Yalnızca soğuk veri. Bir kök kaydın ağacındaki satırlar, GoArchive’ın onları okuduğu andan o kök kaydı tamamlayana kadar değişmemelidir. Bir çökme ve ardından gelen kurtarma süreci de bu kapsama dahildir. Kurtarma süreci, takip günlüğüne kaydedilmiş ve kaynak satırları dışarıdan silinmiş bir kök kaydı, bu durumu fark edemeden tamamlar.
3. Değişen satırlar yeniden kopyalanmaz. GoArchive tarafından kopyalandıktan sonra güncellenen bir kaynak satır yeniden kopyalanmaz, tespit edilmez ve raporlanmaz.

Kaynak ve Hedef Farklı Veritabanları Olmalıdır #

SRC_DEST_IDENTITY_CHECK, aynı sunucu kimliğine ve aynı şema adına sahip bir kaynak ile hedefi reddeder. Aynı sunucu üzerinde farklı bir şema kullanımı desteklenir.

• Şema adları her sunucuda büyük/küçük harf ayrımı gözetilmeden karşılaştırılır; bu nedenle App ve app tek bir şema sayılır ve reddedilir.
• Aynı sunucu kimliğini paylaşan iki sunucu, GoArchive için tek bir sunucudur. Biri diğerinden klonlandığında iki sunucu aynı server_uuid değerini taşır. Bu sunucuların ikisinde de şema adı aynıysa görev reddedilir.
• Her bağlantı, çalıştırma boyunca tek bir arka uç (backend) sunucuya ulaşmalıdır. Aynı hesabın sorgularını farklı sunuculara yönlendiren bir proxy desteklenmez.

Yalnızca InnoDB #

Göreve katılan tüm kaynak ve hedef tablolar InnoDB olmalıdır.

Kapsanmayan Gelen Yabancıl Anahtarlar #

Görevin dışındaki bir tabloda göreve ait bir tabloya başvuran bir yabancıl anahtar (foreign key) bulunması, ON DELETE kuralı ne olursa olsun ölümcül (fatal) bir hatadır. Başka bir şemadaki tablo bir göreve dahil edilemez; bu nedenle şemalar arası gelen bir yabancıl anahtar her zaman ölümcül hatadır. Arşivleme ve kalıcı silme (purge) görevlerinde hiçbir yabancıl anahtarın gözden kaçmadığını kanıtlamak için kaynak hesapta PROCESS yetkisi gerekir.

Hedef Şema Kaynaktan Daha Katı Olmamalıdır #

Hedef şemada ikincil indeksler (secondary indexes), auto_increment ve varsayılan değerler kaldırılabilir; NOT NULL kısıtlamaları da gevşetilebilir. Ancak hedefe, kaynakta bulunmayan kısıtlamalar eklenmemelidir (Hedef Ortam Kontrolleri ).

Tablo Adlarını Küçük Harfle Saklayan Sunucular #

Tablo adlarını küçük harfle saklayan bir sunucuda, görevdeki tüm tablo adlarını küçük harfle yazın. Büyük ve küçük harf karışık bir ad TABLE_EXISTENCE_CHECK ile reddedilir.

Karakter Setleri #

Görevin okuduğu veya yazdığı her metin kolonu desteklenen bir karakter seti kullanmalıdır. Ön kontroller diğer karakter setlerini reddeder (Karakter Setleri ).

JSON Değerleri #

JSON değerleri yazdırılan metin halleriyle kopyalanır. Bu nedenle JSON içindeki bir alanın MySQL veri tipi korunmaz ve bazı değerler kopyalama sırasında değişebilir. sha256 doğrulaması değişen bir değeri reddeder. count ve none modları ise değer karşılaştırması yapmaz; bunun yerine görevin JSON kolonlarını adıyla belirten bir uyarı yazdırır.

Model Sınırları #

Desteklenen İlişki Türleri #

Yalnızca 1:1 ve 1:N ilişkiler desteklenir.

• Çoka çok (N:M) ilişkiler ifade edilemez. Bir tablo bir görevde yalnızca bir kez yer alır. Bu nedenle görevde iki ebeveyni bulunan bir ara tablo (join table) yalnızca tek bir ilişki taşır; bu tablonun ikinci yabancıl anahtarı INTERNAL_FK_COVERAGE kontrolünde başarısız olur.
• Kendine başvuran hiyerarşik tablolar (self-referencing, yani kendi birincil anahtarına işaret eden tablolar) GoArchive ile arşivlenemez. Arşivleme ve kalıcı silme görevleri, ON DELETE CASCADE veya SET NULL kuralı taşıyan böyle bir tabloyu reddeder (SELF_FK_DELETE_RULE_CHECK).

Tablo İlişkileri Kesin Bir Sahiplik Bağını (Ownership) Tanımlamalıdır #

Arşivleme ve kalıcı silme görevleri, geçerli kök yığını için keşfedilen alt kayıt anahtarlarını siler. Bu sırada başka bir kök kaydın bu anahtarlara hâlâ ihtiyaç duyup duymadığını denetlemez.

Yabancıl Anahtarlarda ON DELETE CASCADE #

GoArchive, alt kayıtları ebeveynlerinden önce kendisi siler. İki görev tablosu arasındaki kademeli silme (cascade), GoArchive’ın hesaba katmadığı gereksiz bir iştir; ön kontroller bu durum için uyarı verir.

Veritabanı Tetikleyicileri #

GoArchive, tetikleyicilerin (triggers) içindeki mantığı göremez: Kaynakta başka tabloları değiştiren bir DELETE tetikleyicisi, GoArchive’ın doğrulamadığı yan etkiler doğurur. Ön kontroller hedefteki INSERT tetikleyicilerini reddeder. Kaynaktaki DELETE tetikleyicilerini de geçersiz kılınmadıkça (override) reddeder.

Operasyonel Uyarılar #

Derin veya Geniş Ağaçlar Belleği Tüketebilir #

Keşif aşaması, bir kök yığınına bağlı tüm alt düzey anahtarlarını bellekte tutar. Her düzeyde yüksek dallanma (fan-out) gösteren derin bir ağaç, bu bellek kullanımını sınırsız şekilde büyütebilir: Küçük bir batch_size değeriyle başlayın ve bellek kullanımını izleyerek bu değeri kademeli olarak artırın.

Hedefin max_allowed_packet Değerini Aşan Bir Değer Yığını Başarısız Kılar #

Büyük değerler ayrı olarak gönderildiği için bir satır veya bir INSERT ifadesi hedefin max_allowed_packet değerini aşabilir. Ancak bu değerden büyük tek bir değer gönderilemez: Bu durumda yığına ait hiçbir kayıt takip günlüğüne yazılmaz veya silinmez; hata mesajı tabloyu, kolonu ve boyutu belirtir. Hedefin max_allowed_packet değerini bu boyutun üzerine çıkarın. Her biri uzun veri (long data) eşiğinin hemen altında kalan çok sayıda değer içeren bir INSERT ifadesi ise bütünüyle reddedilebilir: Bu durumda batch_size değerini düşürün.

Group Replication Boyut Sınırını Aşan Bir Veritabanı İşlemi Commit Aşamasında Başarısız Olur #

Group Replication kullanan bir kaynakta, grubun veritabanı işlemi (transaction) boyut sınırını (group_replication_transaction_size_limit) aşan bir silme parçası commit aşamasında başarısız olur. Hiçbir veri kaybolmaz: Kök kayıtlar takip günlüğünde kayıtlı kalır (copied durumunda, purge için deleting durumunda). Her parça bu sınıra sığana kadar batch_delete_size değerini düşürün ve görevi yeniden çalıştırın: Kurtarma süreci bu kayıtları tamamlar. Group Replication kullanan bir hedefte kopyalama işlemi de aynı şekilde başarısız olabilir: Bu durumda batch_size değerini düşürün.

Kopyalama İşlemi Tüm Tabloları Kapsar #

Tek bir hedef veritabanı işlemi, bir yığını tüm tablolar boyunca kopyalar, doğrular ve takip günlüğüne kaydeder. Sonraki tablolar yazılırken, ekleme işlemi tamamlanmış tablolardaki satır kilitleri (row locks) tutulmaya devam eder. Başka iş yüklerinin eşzamanlı olarak okuduğu bir hedef veritabanı kullanmaktan kaçının.

Tasarım Gereği Sıralı Çalışma #

GoArchive her seferinde tek bir yığın işler; paralel işleme yoktur. Görev ağaçları ortak bir kaynak tabloyu paylaşan çalıştırmalar birer birer yürütülür. İlk çalıştırma sürerken şunların tümü reddedilir: Aynı görevin ikinci bir çalıştırması, ağacı çakışan farklı bir kök tablo üzerindeki görev, aynı tabloları başka bir hedefe gönderen görev ve aynı tabloları okuyan iki salt kopyalama (copy-only) görevi (Eşzamanlılık ve Kilitleme ).

Yarım kalmış işi bulunan durdurulmuş bir görev, tablolarından birini paylaşan diğer tüm görevleri engeller. Bu engel, durdurulan görevin yeniden çalıştırması o işi tamamlayana kadar sürer. Bu korumanın sınırları şunlardır:

• Farklı sunuculardaki aynı adlı veritabanları birbirini engeller. Bu durum, veritabanları tek bir job_schema paylaştığında ve kaynak bunları birbirinden ayırt edemediğinde ortaya çıkar. Kaynak şu durumlarda ayırt edemez: gtid_mode değeri ON değilse, kaynak bir Group Replication üyesiyse veya shard’lar birbirinden klonlanarak (türetilerek) yapılandırılmışsa. Her kaynak sunucuya kendi job_schema tanımını verin.
• Korumayla tespit edilemeyen durumlar: Durdurulmuş bir görevin verilerini yalnızca GTID geçişinden önce almış olan sunucular ile bir grubun verisini barındırmasına rağmen grubun dışında kalan bağımsız sunucular otomatik olarak tespit edilemez. Başka bir görev bu tablolarda çalışmadan önce durdurulmuş görevi yeniden bağlayın .
• Korumayla tespit edilemeyen durumlar: Kaynak veritabanının bir replikasında durdurulmuş olarak kayıtlı görevler tespit edilemez.
• Tek takip kaydı (registry): Başka bir job_schema içinde takip edilen durdurulmuş bir görev engel oluşturmaz.

Kilitler tek bir sunucuda tutulur. Bu nedenle her bağlantı, çalıştırma boyunca tek bir arka uç sunucuya ulaşmalıdır: Okuma/yazma ayrımı yapan (read/write-splitting) bir proxy, silme işlemleri birincil sunucuya giderken kilitleri bir replikaya gönderebilir. Bir replikadan okuyan salt kopyalama görevi ile o replikanın birincil sunucusuna yazan bir arşivleme görevi sıraya alınmaz (serialize edilmez); bu durum çalıştırma sözleşmesinin kapsamındadır. Çoklu birincil (multi-primary) modda çalışan Group Replication’da kilitler yalnızca ilgili üyede geçerlidir; bu nedenle farklı üyelere bağlanan çalıştırmalar sıraya alınmaz.

Kesintiden Sonra Kısmi Silmeler #

Kaynakta uzun süreli kilitlerden kaçınmak için silme parçaları ayrı ayrı commit edilir. Alt kayıt silmeleri ile ebeveyn silmeleri arasında durdurulan bir çalıştırma, ebeveyn kaydı yerinde bırakırken alt kayıtları silinmiş halde bırakır. Bu durum, bir sonraki başlatmada kurtarma süreci kök kaydı tamamlayana kadar sürer. Satırlar silinmeden önce kopyalanmış ve doğrulanmıştır; ancak çalıştırma sırasında ilişkisel bütünlüğü (referential integrity) denetleyen bir izleme sistemi bu boşluğu görebilir.

Salt Kopyalama Yeniden Çalıştırmaları Tüm Aralığı Yeniden Tarar #

Kontrol noktası (checkpoint) bulunmaz. Bu nedenle resume: true ile yeniden çalıştırılan bir salt kopyalama görevi, daha önce kopyaladığı kök kayıtları atlamak için where aralığının tamamını yeniden okur. Çok büyük bir aralıkta bu, her çalıştırmada tam bir tarama maliyeti anlamına gelir.

Yerleşik Metrik Yoktur #

GoArchive bir metrik uç noktası (metrics endpoint) sunmaz. Bunun yerine --progress ilerleme göstergesini , yapılandırılmış günlükleri (structured logs) ve takip tablolarını kullanın.

Hatalı Yapılandırmada Veri Kaybı Mümkündür #

Doğrulama, niyeti değil yapıyı denetler: Yanlış where koşuluna sahip bir görev yanlış satırları siler. archive komutunu çalıştırmadan önce where koşulunu verilere ve dry-run çıktısındaki ilk yığına karşı kontrol edin; geçerli yedekler bulundurun.

Güven Modeli #

GoArchive operatörü kendi hatalarına karşı korur, operatörün kendisine karşı değil. Yapılandırma dosyası güvenilir bir girdi kabul edilir: Bu dosyayı yazan kişi, içinde adı geçen kimlik bilgilerine zaten sahiptir.

• Görevlerdeki where değerleri tasarım gereği serbest SQL koşullarıdır. Yalnızca tablo ve kolon tanımlayıcıları (identifiers) doğrulanır.
• Yapılandırmayı yazan kişi kimlik bilgilerinin sahibi değilse, güvenlik sınırını dosyada adı geçen hesapların yetkileri belirler: Yalnızca yetki matrisinde listelenen yetkileri verin.
• Bir yığının kaynak satırları silindikten sonra arşivlenen satırlar yalnızca hedefte bulunur. Bu satırların dayanıklılık (durability), replikasyon ve yedekleme yoluyla güvende tutulması GoArchive’ın kapsamı dışındadır.

Yapılandırma dosyasını düzenleme olanağını güvenilmeyen kullanıcılara veya güvenilmeyen otomasyon araçlarına açmayın.