Bu, iki farklı motorda iki kez gördüğüm bir arıza. Bir dışa aktarma 10:00'da çalışır ve gördüğü en yüksek son değişiklik zaman damgasını kaydeder. 09:58'de başlayan bir işlem hâlâ açıktır, 10:03'te commit eder ve başladığı andan bir zaman damgası taşır. Sonraki dışa aktarma yalnızca 10:00'dan yeni satırları ister ve onu asla görmez. Aktarım boyutu mükemmeldi ve veriler yanlıştı.

Bir satırı kaybeden dışa aktarmayı izleyin

SQL'i değil, olayların sırasını izleyin. Uygulama satırın değişiklik zamanını işlem başladığında yazar, commit edildiğinde değil. Dışa aktarıcı, o işlem hâlâ açıkken duvar saati su işaretini okur. Ardından işlem, kaydedilen su işaretinden daha eski bir değişiklik zamanıyla commit eder. Tüketicinin sonraki partisi su işaretinden sonra başlar, bu yüzden satır imlecin arkasında kalır ve bir daha asla seçilmez.

Hiçbir şey hata kaydetmez, çünkü hiçbir şey başarısız olmadı. Bu hata sınıfını pahalı yapan da budur: delta akışı hızlıdır, satır sayıları makul görünür ve eksik satır haftalar sonra kimsenin yeniden üretemediği bir mutabakat bileti olarak ortaya çıkar.

Sıra numaraları başka bir nedenle aynı biçimde kusurludur. Monoton bir ID, değerlerin hangi sırayla tahsis edildiğini söyler, işlemlerin hangi sırayla commit ettiğini değil. Düşük numara alan bir işlem, yüksek numara alanın ardından commit edebilir, bu yüzden tahsis sırasına dayanan bir imleç de boşluk bırakabilir.

Akışın vermesi gereken beş söz

Bir taşıma seçmeden önce kaynak sistemden beş maddelik bir sözleşme isteyin. Herhangi bir madde eksikse elinizde değişiklik akışı değil, bir sezgi vardır.

  • Kapsam: eklemeler, güncellemeler ve silmeler, her biri uygulamak için gereken kararlı anahtarla.
  • Sınır: bir imleç değerinin ne anlama geldiği ve tutarlı bir partinin ne içerdiği.
  • Tutarlılık: ilgili tabloların uyumsuz kaynak durumlarını karıştırmadan nasıl okunduğu.
  • Saklama: bağlantısı kesilmiş bir tüketicinin kayıtlı konumundan ne kadar süre devam edebileceği.
  • Yeniden başlatma: o konum artık geçerli olmadığında desteklenen tam anlık görüntü.

Desteklenen bir mekanizma beşini de karşılayabilir. SQL Server'ın değişiklik izleme belgeleri somut, yayımlanmış bir örnektir: en düşük geçerli sürümü tanımlar, değişikliklerin yanı sıra silmeleri de kaydeder ve doğrulama, sürüm yakalama ile ilgili değişiklik sorgularını kapsayan bir anlık görüntü işlemini açıklar. Bu, bir kaynaktan talep edilmesi gerekenlerin örneğidir, başka bir motora yapıştırabileceğiniz sözdizimi değil.

Kontrol noktasını işlem hattının parçası olarak tasarlayın

Tüketicinin kayıtlı konumu gerçek durum makinesidir, bu yüzden onu öyle yazın. İmleç yalnızca partiyi zaten uygulamış ve hedef işlemi commit etmiş iş akışı aracılığıyla ilerleyebilir.

cursor  = durable_checkpoint()          # last fully applied position
batch   = extract(cursor, upper_bound)  # one consistent batch
apply(batch)                            # idempotent at the target
commit()
checkpoint(batch.upper_bound)           # only now

Teslimat yarı yolda başarısız olursa, yeni bir kaynak konumu icat etmek yerine aynı partiyi mutabakata bağlayın. Daha yeni bir üst sınırla yeniden çıkarmak, kısmi uygulamanın kalıcı bir boşluğa dönüşme yoludur. Ayna kuralı diğer tarafta da geçerlidir: hedefte eşgüçlü (idempotent) uygulama yinelenenleri önler ve çıkarmanın hiç görmediği bir değişiklik için hiçbir şey yapmaz.

Silmeler kayıt ister, sonuç değil

Hâlâ var olan satırları karşılaştırmak, hangi anahtarların kaybolduğunu tüketiciye söyleyemez. Silmeleri asla kaydetmeyen bir kaynak size iki kusurlu seçenek bırakır: fark almak için yeterince uzun bir anahtar geçmişi tutmak veya zamanlamaya göre açık bir tam mutabakat çalıştırmak. İkisi de maliyeti olan tasarım kararlarıdır ve bir sahibi yoksa hiçbiri var olmaz.

Saklama da aynı tür karardır. Desteklenen her değişiklik akışının bir penceresi vardır; bunu sözleşmede belirtin ve bir tüketicinin kontrol noktası ona yaklaştığında uyarın. İki haftalık kesintiden sonra uyanan bir tüketici sessizce kısmi bir parti almak yerine açık bir "yeniden başlatma gerekli" hatası okumalıdır.

Sonra deltanın buna değip değmediğini ölçün

Her anahtarı ve karmayı karşılaştırmaya dönmek bazen doğrudur ve maliyetini bilmek buna değer. Yine de her satır hakkında bilgi aktarırsınız, karmalar size tablolar arası tutarlı bir anlık görüntü vermez ve karma şeması temsil ve çakışmalar hakkında kendi sorularını getirir. Doğrulanabilir bir sınırla daha az bayt hedeftir; commit edilmiş bir değişikliği sessizce düşüren daha az bayt delta bile değildir.

Son değişiklik sütunu bir ipucudur. Geç bir commit'i, bir silmeyi ve uzun bir kesintiyi atlatan imleç bir sözleşmedir.

İlgili makaleler