Kontrol noktalarıyla kademeli veri eşitleme: sistemleri güvenle hizalayın

Neden her şeyi tekrar içe aktarmak sürekli sorun yaratır

Tam yeniden aktarımlar güvenli hissettirir çünkü basittir gibi görünür: sil, yeniden yükle, bitti. Gerçekte, bunlar yavaş senkronlar, daha yüksek faturalar ve karmaşık veriler yaratmanın en kolay yollarından biridir.

İlk sorun zaman ve maliyettir. Her koşuda tüm veri setini çekmek aynı kayıtları tekrar tekrar yeniden indirmeniz anlamına gelir. Örneğin her gece 500.000 müşteriyi senkronluyorsanız, yalnızca 200 kayıt değişmiş olsa bile işlem, API çağrıları ve veritabanı yazımları için ödeme yaparsınız.

İkinci sorun doğruluktur. Tam yeniden aktarımlar genellikle çiftler oluşturur (eşleme kuralları kusursuz değildir) veya dışarı aktarmada yer alan daha eski verilerle daha yeni düzenlemeleri üstüne yazar. Birçok ekip ayrıca “sil ve yeniden yükle” yarıda başarısız olduğunda toplamların zaman içinde kaydığını görür.

Tipik belirtiler şöyle görünür:

• Bir çalışma sonrası sistemler arasındaki sayımlar eşleşmiyor
• Kayıtlar küçük farklarla iki kez görünüyor (e-posta büyük/küçük harf, telefon formatı)
• Yeni güncellenmiş alanlar eski bir değere geri dönüyor
• Senkron bazen “bitti” diyor ama bir parça veriyi kaçırıyor
• Her içe aktarma penceresinden sonra destek talepleri artıyor

Bir kontrol noktası, "buraya kadar işledim" diyen küçük bir kaydedilmiş işarettir. Sonraki sefer, başlangıç yapmak yerine o işaretçiden devam edersiniz. İşaret bir zaman damgası, kayıt kimliği, sürüm numarası veya bir API tarafından döndürülen bir token olabilir.

Gerçek hedefiniz iki sistemi zaman içinde uyumlu tutmaksa, kontrol noktalarıyla kademeli veri eşitleme genellikle daha iyi bir hedeftir. Veriler sık değişiyorsa, dışa aktarımlar büyükse, API'lerin hız sınırları varsa veya bir çökme sonrası (örneğin AppMaster gibi bir platformda oluşturduğunuz dahili araçta bir iş yarıda kalırsa) güvenli şekilde devam etmesi gerekiyorsa özellikle faydalıdır.

Yöntem seçmeden önce senkron hedefini tanımlayın

Kontrol noktalarıyla kademeli veri eşitleme, "doğru"nun nasıl göründüğünü net bilmekle iyi çalışır. Bunu atlayıp doğrudan imleçlere veya özetlere geçerseniz, genellikle kurallar yazılmadığı için senkronu yeniden kurmak zorunda kalırsınız.

Önce sistemleri adlandırın ve hangi tarafın gerçeğin sahibi olduğunu kararlaştırın. Örneğin CRM'iniz müşteri adları ve telefon numaraları için gerçek kaynak olabilir, faturalama aracınız abonelik durumu için gerçek kaynak olabilir. Eğer her iki sistem de aynı alanı düzenleyebiliyorsa tek bir gerçek kaynağınız yok demektir ve çatışmalar için plan yapmalısınız.

Sonra “uyumlu”nun ne anlama geldiğini tanımlayın. Her zaman tam eşleşmeye mi ihtiyacınız var, yoksa güncellemelerin birkaç dakika içinde görünmesi yeterli mi? Tam eşleşme genellikle daha sıkı sıralama, kontrol noktaları etrafında güçlü garantiler ve delete işlemlerinin daha dikkatli ele alınmasını gerektirir. Nihai tutarlılık genellikle daha ucuzdur ve geçici hatalara karşı daha hoşgörülüdür.

Senkron yönünü de kararlaştırın. Tek yönlü senkron daha basittir: Sistem A, Sistem B'yi besler. İki yönlü senkron daha zordur çünkü her güncelleme bir çatışma olabilir ve her iki tarafın birbirini sürekli "düzeltmesini" önlemeniz gerekir.

İnşa etmeden önce cevaplanması gereken sorular

Herkesin kabul ettiği basit kuralları yazın:

• Hangi sistem hangi alan(lar) için gerçek kaynaktır (veya her nesne türü için)?
• Kabul edilebilir gecikme nedir (saniye, dakika, saat)?
• Bu tek yönlü mü yoksa iki yönlü mü, hangi olaylar hangi yönde akıyor?
• Silmeler nasıl ele alınır (kalıcı silme, yumuşak silme, mezar taşları)?
• İki taraf aynı kaydı değiştirdiğinde ne olur?

Pratik bir çatışma kural seti şöyle basit olabilir: "abonelik alanları için faturalama kazanır, iletişim alanları için CRM kazanır, aksi halde en yeni güncelleme kazanır." AppMaster gibi bir araçta entegrasyonu inşa ediyorsanız, bu kuralları Business Process mantığında yakalayın ki görünür ve test edilebilir kalsın, birinin hafızasında kaybolmasın.

İmleçler, özetler ve devam tokenleri: yapı taşları

Kontrol noktalarıyla kademeli veri eşitleme genellikle güvenle saklayıp yeniden kullanabileceğiniz üç "pozisyondan" birine dayanır. Doğru seçim, kaynak sistemin neyi garanti edebildiğine ve hangi hataları kurtarmak gerektiğine bağlıdır.

Bir imleç kontrol noktası en basitidir. "İşlediğim son şey"i saklarsınız; örneğin son ID, son updated_at zaman damgası veya bir sıra numarası. Bir sonraki çalışmada o noktadan sonraki kayıtları istersiniz. Bu, kaynak tutarlı sıralıyorsa ve ID'ler ya da zaman damgaları güvenilir bir şekilde ilerliyorsa iyi çalışır. Gecikmeli güncellemeler, saatlerin farklı olması veya kayıtların "geçmişe" eklendiği durumlarda (ör. backfill) bozulur.

Özetler (hash) imleç tek başına yeterli olmadığında değişiklikleri tespit etmenize yardımcı olur. Her kaydı (önem verdiğiniz alanlara göre) hashleyip sadece hash değiştiğinde senkronlayabilirsiniz. Ya da sürükleyici bir drift tespiti için tüm bir partiyi hashleyip sonra ayrıntıya inebilirsiniz. Kayıt başına özetler kesin ama depolama ve işlem maliyeti ekler. Parti özetleri ise daha ucuzdur ama hangi öğenin değiştiğini gizleyebilir.

Devam tokenleri, kaynak tarafından genellikle sayfalandırma veya olay akışları için verilen opak değerlerdir. Onları yorumlamazsınız, sadece saklar ve devam etmek için geri gönderirsiniz. Tokenler API karmaşıksa harikadır, ama süresi dolabilir, tutma penceresinden sonra geçersiz olabilir veya ortamlara göre farklı davranabilir.

Ne kullanmalı ve neler ters gidebilir

• İmleç: hızlı ve basit, ama sıradışı güncellemelere dikkat edin.
• Kayıt başına özet: hassas değişiklik tespiti, ama maliyeti daha yüksek.
• Parti özeti: ucuz drift sinyali, ama çok spesifik değil.
• Devam tokeni: en güvenli sayfalandırma, ama süresi dolabilir veya tek kullanımlık olabilir.
• Hibrit (imleç + özet): updated_at tamamen güvenilir değilse yaygın bir kombinasyondur.

AppMaster gibi bir araçta senkron inşa ediyorsanız, bu kontrol noktaları genellikle küçük bir "sync state" tablosunda yaşar, böylece her çalışma tahmin etmeden yeniden başlayabilir.

Kontrol noktası depolamasını tasarlamak

Kontrol noktası depolaması, kontrol noktalarıyla kademeli veri eşitlemeyi güvenilir kılan küçük parçadır. Okuması zor, üzerine yazması kolay veya belirli bir işe bağlı değilse, senkronunuz bir süre iyi görünür ama bir kez başarısız olduğunda tahmin yürütürsünüz.

Önce kontrol noktalarının nerede yaşayacağını seçin. Veritabanı tablosu genellikle en güvenlisidir çünkü işlemleri, denetimi ve basit sorguları destekler. Bir anahtar-değer store işe yarayabilir eğer zaten kullanıyorsanız ve atomik güncellemeleri destekliyorsa. Bir yapılandırma dosyası sadece tek kullanıcı, düşük riskli senkronlar için makul çünkü kilitlemesi zor ve kaybetmesi kolaydır.

Ne saklanmalı (ve neden)

Bir kontrol noktası sadece bir imleçten daha fazladır. Hata ayıklamak, devam etmek ve drift tespit etmek için yeterli bağlamı saklayın:

• İş kimliği: iş adı, tenant veya hesap id'si, nesne türü (örneğin customers)
• İlerleme: imleç değeri veya devam tokeni, artı imleç tipi (zaman, id, token)
• Sağlık sinyalleri: son çalışma zamanı, durum, okunan ve yazılan kayıt sayısı
• Güvenlik: son başarılı imleç (sadece son denenmiş olan değil) ve son hataya kısa bir hata mesajı

Eğer değişiklik tespiti için özetler kullanıyorsanız, özet yöntemi versiyonunu da saklayın. Aksi takdirde daha sonra özet algoritmasını değiştirip her şeyi "değişti" gibi değerlendirebilirsiniz.

Versiyonlama ve çok sayıda senkron işi

Veri modeliniz değiştiğinde kontrol noktalarınızı versiyonlayın. En kolay yaklaşım bir schema_version alanı eklemek ve yeni bir sürüm için yeni satırlar oluşturmak, eski verileri değiştirmemektir. Geri alma için eski satırları bir süre saklayın.

Birden fazla senkron işi için her şeyi isim alanına alın. İyi bir anahtar (tenant_id, integration_id, object_name, job_version) olur. Bu, iki işin aynı imleci paylaşıp sessizce veriyi atlama klasİk hatasını önler.

Somut örnek: senkronu AppMaster içinde bir dahili araç olarak inşa ediyorsanız, kontrol noktalarını PostgreSQL'de tenant ve nesne başına bir satır olarak saklayın ve yalnızca başarılı bir parti commitinden sonra güncelleyin.

Adım adım: kademeli bir senkron döngüsünü uygulamak

Kontrol noktalarıyla kademeli veri eşitleme, döngünüz sıkıcı ve öngörülebilir olduğunda en iyi çalışır. Hedef basittir: dengeli bir sırada değişiklikleri okuyun, güvenli bir şekilde yazın, sonra yazmanın yapıldığını öğrendiğinizde kontrol noktasını ilerletin.

Güvenilir basit bir döngü

Önce aynı kayıt için asla değişmeyen bir sıralama seçin. Zaman damgaları işe yarayabilir, ancak iki güncellemenin aynı anda olmaması için bir tie-breaker (örneğin bir ID) de ekleyin.

Sonra döngüyü şu şekilde çalıştırın:

• İmlecinizi belirleyin (örneğin: last_updated + id) ve sayfa boyutunu seçin.
• Saklı kontrol noktasından daha yeni olan bir sonraki kayıt sayfasını alın.
• Her kaydı hedefe upsert edin (yoksa oluştur, varsa güncelle) ve hataları yakalayın.
• Başarılı yazımları commit edin, ardından son işlenen kaydın yeni kontrol noktasını saklayın.
• Tekrar edin. Sayfa boşsa uyuyun, sonra tekrar deneyin.

Kontrol noktası güncellemesini alınmadan ve fetch işleminden ayrı tutun. Kontrol noktasını çok erken kaydederseniz, bir çökme veriyi sessizce atlayabilir.

Çoğaltma olmadan geri çekilme ve tekrar denemeler

Çağrıların hata vereceğini varsayın. Bir fetch veya yazma başarısız olduğunda kısa bir geri çekilme ile (örneğin: 1s, 2s, 5s) ve maksimum tekrar sayısı ile yeniden deneyin. Yeniden denemeleri güvenli hale getirmek için upsert kullanın ve yazımlarınızı idempotent yapın (aynı giriş, aynı sonuç).

Küçük, uygulamalı bir örnek: müşteri güncellemelerini her dakika senkronluyorsanız, aynı anda 200 değişiklik çekip onları upsert edebilir ve yalnızca sonra son müşterinin (updated_at, id) değerini yeni imleç olarak saklayabilirsiniz.

AppMaster içinde bunu kuruyorsanız, kontrol noktasını basit bir tabloda (Data Designer) modelleyip döngüyü Bir İş Sürecinde fetch, upsert ve kontrol noktası güncellemesi olarak koşabilirsiniz.

Yeniden başlamayı güvenli kılmak: idempotentlik ve atomik kontrol noktaları

Senkronunuz yeniden başlayabiliyorsa, en kötü zamanda yeniden başlayacaktır: bir zaman aşımından, çökmeden veya kısmi bir deploy sonrası. Hedef basit: aynı parti tekrar çalıştırıldığında çoğaltma yaratmamalı veya güncellemeleri kaybetmemelisiniz.

Idempotentlik güvenlik ağıdır. Bunu tekrar edilebilir şekilde yazma ile elde edersiniz. Pratikte bu genellikle insert yerine upsert demektir: kaydı stabil bir anahtar (örneğin customer_id) kullanarak yazın ve zaten varsa mevcut satırı güncelleyin.

İyi bir "yazma anahtarı", tekrarlar boyunca güvenebileceğiniz bir şeydir. Yaygın seçenekler kaynak sistemden gelen doğal bir ID veya kaydı ilk gördüğünüzde oluşturduğunuz sentetik bir anahtardır. Benzersiz kısıtlama ile destekleyin ki iki worker yarışsa bile veritabanı kuralınızı uygulasın.

Atomik kontrol noktaları da bir o kadar önemlidir. Kontrol noktasını veriler commit edilmeden ilerletirseniz, bir çökme kayıtları sonsuza dek atlamanıza neden olabilir. Kontrol noktası güncellemesini yazma işleminin aynı başarı sınırının bir parçası gibi ele alın.

Kontrol noktalarıyla kademeli senkron için basit bir desen:

• Son kontrol noktasından beri olan değişiklikleri okuyun (imleç veya token).
• Her kaydı deduplikasyon anahtarıyla upsert edin.
• İşlemi commit edin.
• Yalnızca sonra yeni kontrol noktasını saklayın.

Sıradışı güncellemeler ve gecikmeli gelen veriler diğer yaygın tuzaktır. Bir kayıt 10:01'de güncellenmiş olabilir ama 10:02'den sonra gelebilir; veya bir API tekrar denemede daha eski değişiklikleri teslim edebilir. Kendinizi korumak için bir kaynak "last_modified" saklayın ve "son yazma kazanır" kuralı uygulayın: gelen kayıt, mevcut olandan daha yeni ise üzerine yazın.

Daha güçlü koruma gerekiyorsa, küçük bir örtüşme penceresi tutun (örneğin son birkaç dakikayı yeniden oku) ve idempotent upsert'lere güvenin. Bu biraz ekstra iş ekler ama yeniden başlatmaları sıkıcı kılar; tam da istediğiniz şey budur.

AppMaster'da aynı fikir, İş Süreci akışına temizce uyar: önce upsert mantığını yapın, commit edin, sonra imleç veya devam tokenini son adım olarak saklayın.

Kademeli senkronu bozan yaygın hatalar

Çoğu senkron hatası koddan çok varsayımlardan kaynaklanır. Eğer kontrol noktalarıyla kademeli veri eşitlemenin güvenilir kalmasını istiyorsanız, bu tuzaklara erken dikkat edin.

Olağan başarısızlık noktaları

Yaygın bir hata updated_ate fazla güvenmektir. Bazı sistemler backfill, zaman dilimi düzeltmeleri, toplu düzenlemeler veya okuma-düzeltmeleri sırasında zaman damgalarını yeniden yazar. Eğer imleciniz sadece bir zaman damgasıysa, kayıtları kaçırabilirsiniz (zaman damgası geriye doğru atlar) veya büyük aralıkları tekrar işleriz (zaman damgası ileri sıçrarsa).

Başka bir tuzak ID'lerin sürekli veya kesin artan olduğunu varsaymaktır. İçe aktarımlar, sharding, UUID'ler ve silinmiş satırlar bu fikri kırar. "Son görülen ID"yi kontrol noktası olarak kullanırsanız, boşluklar ve sıradışı yazımlar kayıtların geride kalmasına neden olabilir.

En zararlı hata, kontrol noktasını kısmi başarı üzerine ilerletmektir. Örneğin 1.000 kayıt çekersiniz, 700 yazarsınız, sonra çökersiniz ama yine de fetch'ten gelen "sonraki imleç"i saklarsınız. Yeniden başladığınızda kalan 300 hiç yeniden denenmez.

Silmeleri de göz ardı etmek kolaydır. Bir kaynak yumuşak silme (işaret), kalıcı silme (satır kaldırıldı) veya "yayından kaldırma" (durum değişikliği) yapabilir. Sadece aktif kayıtları upsert ederseniz hedef yavaşça sapar.

Son olarak, şema değişiklikleri eski özetleri geçersiz kılabilir. Değişiklik tespiti özetleriniz bir alan kümesinden oluşturulduysa, bir alan eklemek veya yeniden adlandırmak "değişmedi"yi "değişti" gibi gösterebilir; bu yüzden özet mantığınızı versiyonlayın.

Daha güvenli varsayılanlar:

• Mümkünse ham zaman damgaları yerine monotonik bir imleci (olay ID'si, log pozisyonu) tercih edin.
• Kontrol noktası yazımlarını veri yazımlarıyla aynı başarı sınırı içinde tutun.
• Silmeleri açıkça takip edin (mezar taşları, durum geçişleri veya periyodik uzlaştırma).
• Özet girdilerinizi versiyonlayın ve eski sürümleri okunabilir tutun.
• Kaynağın güncellemeleri yeniden sıralayabildiği durumlarda küçük bir örtüşme penceresi ekleyin (son N öğeyi yeniden oku).

AppMaster kullanıyorsanız, kontrol noktasını Data Designer'da kendi tablosu olarak modelleyin ve "veriyi yaz + kontrol noktasını yaz" adımını tek bir business process çalıştırmasında tutun, böylece retry'ler işi atlamaz.

Gürültü yapmadan izleme ve sapma tespiti

Kontrol noktalarıyla kademeli veri eşitleme için iyi izleme, "daha fazla log"tan çok her çalışmada güvenebileceğiniz birkaç sayı ile ilgilidir. "Ne işledik, ne kadar sürdü ve nereden devam edeceğiz?" sorularına cevap verebiliyorsanız, çoğu sorunu dakikalar içinde çözebilirsiniz.

Başlamak için her senkron çalıştığında tek bir özlü çalışma kaydı yazın. Tutarlı tutun ki çalışmaları karşılaştırıp trendleri görebilesiniz.

• Başlangıç imleci (veya devam tokeni) ve bitiş imleci
• Çekilen kayıtlar, yazılan kayıtlar, atlanan kayıtlar
• Çalışma süresi ve kayıt başına ortalama süre (veya sayfa başına)
• Hata sayısı ve en yaygın hata nedeni
• Kontrol noktası yazma durumu (başarılı/başarısız)

Sapma tespiti bir sonraki katmandır: iki sistem "her ikisi de çalışıyor" gibi görünse bile yavaşça ayrıldıklarında size haber verir. Sadece toplamlar yanıltıcı olabilir, bu yüzden hafif bir toplam kontrolünü küçük örnek kontrollerle birleştirin. Örneğin günde bir kez her iki sistemdeki aktif müşteri toplamını karşılaştırın, sonra rastgele 20 müşteri ID'si örnekleyip birkaç alanı doğrulayın (durum, updated_at, e-posta). Eğer toplamlar farklı ama örnekler eşleşiyorsa silmeleri veya filtreleri kaçırıyor olabilirsiniz. Eğer örnekler farklıysa, değişiklik tespiti özetleriniz veya alan eşlemeniz muhtemelen yanlıştır.

Uyarılar nadir ve eyleme geçirilebilir olmalıdır. Basit bir kural: bir insanın şimdi müdahale etmesi gerekiyorsa uyarı verin.

• İmleç takıldı (bitiş imleci N çalışma boyunca ilerlemiyor)
• Hata oranı yükseliyor (örneğin 1% -> 5% bir saat içinde)
• Çalışmalar yavaşlıyor (süre normal üst sınırınızın üzerinde)
• Birikim büyüyor (yeni değişiklikler senkronizasyon hızınızdan daha hızlı geliyor)
• Sapma onaylandı (iki kontrolte toplamlar tutmuyor)

Bir başarısızlıktan sonra manuel temizlik yapmadan güvenli şekilde yeniden çalıştırın. En kolay yaklaşım son commit edilmiş kontrol noktasından devam etmektir, "görülen son" kayıttan değil. Eğer küçük bir örtüşme penceresi kullanıyorsanız (son sayfayı yeniden oku), yazımları idempotent yapın: stabil ID ile upsert edin ve yazım başarılı olduktan sonra kontrol noktasını ilerletin. AppMaster'da takımlar genellikle bu kontrolleri bir Business Process akışında uygular ve hata görünürlüğü için e-posta/SMS veya Telegram modülleriyle uyarı gönderirler.

Göndermeden önce hızlı kontrol listesi

Üretime almadan önce kontrol noktalarıyla kademeli veri eşitlemeyi etkinleştirmeden önce genellikle geç sürprizlere neden olan birkaç detayı hızlıca gözden geçirin. Bu kontroller birkaç dakika alır ama "neden kayıtları kaçırdık?" hata ayıklamalarının günlerini önler.

İşte pratik bir gönderim öncesi kontrol listesi:

• Sıralama için kullandığınız alanın (zaman damgası, sıra, ID) gerçekten stabil olduğundan ve kaynak tarafta indexli olduğundan emin olun. Eğer sonradan değiştirebiliyorsa, imleciniz sapar.
• Upsert anahtarınızın kesinlikle benzersiz olduğunu ve her iki sistemin de bunu aynı şekilde ele aldığını doğrulayın (büyük/küçük harf duyarlılığı, kırpma, formatlama). Bir sistem "ABC" saklarken diğeri "abc" saklıyorsa çiftler oluşur.
• Her iş ve her veri seti için kontrol noktalarını ayrı tutun. "Küresel son imleç" basit görünür ama iki tabloyu, iki tenant'ı veya iki filtreyi senkronize ettiğinizde bozulur.
• Kaynak nihai tutarlıysa, küçük bir örtüşme penceresi ekleyin. Örneğin "last_updated = 10:00:00"den devam ederken 09:59:30'dan yeniden başlamak ve idempotent upsert'lere güvenmek iyi bir yaklaşımdır.
• Hafif bir uzlaştırma planlayın: zamanlanmış olarak küçük bir örnek set (ör. 100 rastgele kayıt) seçip ana alanları karşılaştırarak sessiz sapmayı yakalayın.

Kısa bir gerçeklik testi: senkronu bir çalışmanın ortasında durdurun, yeniden başlatın ve aynı sonuçla bittiğini doğrulayın. Yeniden başlatma sayıları değiştiriyor veya ekstra satırlar oluşturuyorsa, yayına almadan önce bunu düzeltin.

AppMaster'da senkron akışının her entegrasyon için checkpoint verilerini ilgili sürece ve veri setine bağlayın; ilgisiz otomasyonlarla paylaşmayın.

Örnek: İki uygulama arasında müşteri kayıtlarını senkronlamak

Basit bir kurgu hayal edin: CRM'iniz kişiler için gerçek kaynak ve aynı kişilerin bir destek aracında (biletlerin gerçek müşteriye eşlenmesi için) veya bir müşteri portalında (kullanıcılar giriş yapıp hesaplarını görebilsin diye) olmasını istiyorsunuz.

İlk çalışmada bir kezlik bir import yapın. Kişileri stabil bir sırayla çekin; örneğin tie-breaker olarak id ile birlikte updated_at kullanın. Her partiyi hedefe yazdıktan sonra şunu içeren bir kontrol noktası saklayın: last_updated_at ve last_id. Bu kontrol noktası gelecekteki her çalışma için başlangıç çizginiz olur.

Sürekli çalışmalarda sadece kontrol noktasından daha yeni olan kayıtları çekin. Güncellemeler basittir: CRM kaydı zaten varsa destinasyonu güncelleyin; yoksa oluşturun. Birleştirmeler zordur. CRM'ler sık sık çoğaltmaları birleştirir ve bir "kazanan" kayıt tutar. Bunu kazananı işaretleyip kaybettireni pasif hale getiren bir güncelleme olarak ele alın, böylece aynı kişi için iki portal kullanıcısı oluşmaz.

Silmeler normal "güncellemeden itibaren" sorgularında nadiren görünür, bu yüzden bunlar için plan yapın. Yaygın seçenekler kaynakta bir yumuşak-silme bayrağı, ayrı bir "silinenler" beslemesi veya eksik ID'leri kontrol eden periyodik hafif bir uzlaştırmadır.

Şimdi hata durumuna bakalım: senkron yarıda çöktü. Eğer kontrol noktasını yalnızca sonunda saklıyorsanız, büyük bir parçayı yeniden işlemiş olursunuz. Bunun yerine parti başına bir resume token kullanın.

• Bir çalışma başlatın ve bir run_id (devam tokeniniz) oluşturun
• Bir partiyi işleyin, destinasyona yazın, sonra atomik olarak run_id ile ilişkilendirilmiş kontrol noktasını kaydedin
• Yeniden başlangıçta, o run_id için kaydedilmiş son kontrol noktasını bulun ve oradan devam edin

Başarı sıkıcı görünür: sayımlar gün be gün sabit kalır, çalışma süreleri öngörülebilir olur ve aynı pencereyi tekrar çalıştırmak beklenmeyen değişiklik üretmez.

Sonraki adımlar: bir desen seçin ve daha az yeniden çalışma ile inşa edin

İlk kademeli döngünüz çalıştıktan sonra, yeniden çalışma olmaması için en hızlı yol senkron kurallarını yazılı hale getirmektir. Kısa tutun: hangi kayıtlar kapsamda, çatışmalarda hangi alanlar kazanır ve her çalışmadan sonra "bitti"nin ne olduğu.

Küçük başlayın. Bir veri seti seçin (ör. customers) ve uçtan uca çalıştırın: ilk import, kademeli güncellemeler, silmeler ve kasıtlı bir hatadan sonra resume. Beş tablo eklemeden önce varsayımları düzeltmek daha kolaydır.

Tam bir yeniden kurulum bazen doğru karardır. Bunu yapın kontrol noktası durumu bozulduğunda, kimlikleri değiştirdiğinizde veya şema değişikliği değişiklik tespitini bozduğunda (örneğin bir özet kullandıysanız ve alanların anlamı değiştiyse). Yeniden kurulum yaparsanız bunu acil bir düğme değil kontrollü bir operasyon olarak ele alın.

Sorunsuz bir yeniden import yapmanın güvenli yolu:

• Mevcut canlı veriyi bırakıp gölge bir tabloya veya paralel bir veri setine import yapın.
• Sayımları doğrulayın ve örnek kontroller yapın, kenar durumları (null'lar, birleştirilmiş kayıtlar) dahil.
• İlişkileri backfill edin, sonra okuyucuları planlı bir cutover ile yeni veri setine yönlendirin.
• Eski veri setini kısa bir geri alma penceresi için saklayın, sonra temizleyin.

Kod yazmadan bunu inşa etmek istiyorsanız, AppMaster parçaları tek bir yerde tutmanıza yardımcı olabilir: veriyi PostgreSQL'de Data Designer ile modelleyin, senkron kurallarını Business Process Editor'da tanımlayın ve kayıtları çekip dönüştürüp upsert eden zamanlanmış işler çalıştırın. AppMaster gereksinimler değiştiğinde temiz kod ürettiği için "bir alan daha eklemeliyiz" demek daha az risklidir.

Daha fazla veri setine genişlemeden önce senkron sözleşmenizi belgeleyin, bir desen seçin (imleç, devam tokeni veya özet) ve bir senkronu tamamen güvenilir hale getirin. Sonra aynı yapıyı başka bir veri seti için tekrarlayın. Hızlı denemek isterseniz, AppMaster'da bir uygulama oluşturup küçük bir planlı senkron işi çalıştırarak başlayın.