Büyük veritabanlarında yanlış veri güncellemelerinden kaçınmak için izlediğiniz uygulamalar nelerdir?

Herhangi bir üretim dağıtımından önce verilen tipik bir tavsiye, önce DB'yi yedeklemektir. Bu şekilde, yeni güncellemede potansiyel veri kaybına veya mantıksal veri bozulmasına yol açabilecek bir sorun varsa, eski kayıtları karşılaştırmak ve düzeltmek için bir yedeğiniz vardır.

Ancak, DB boyutu birkaç GBs olana kadar bu iyi çalışabilir. DB boyutu büyük olduğunda, yedeklemelerin tamamlanması uzun zaman alır. Bir kod dağıtımındaki mantıksal sorunlar nedeniyle mantıksal veri bozulmasını önlemek için bu gibi durumlarda uygulanması gereken en iyi uygulamalar nelerdir?

Yazılım yükseltmelerimiz için müşteriler için üretim veritabanının güncellenmesi ile düzenli olarak ilgilenen biri olarak, hataları en aza indirmenin en iyi yolunun güncellemeleri olabildiğince basit yapmak olduğunu söylüyorum.

Belirli kayıtlar yerine tüm kayıtlarda değişiklik yapabiliyorsanız, bu tercih edilir.

Başka bir deyişle, durumlarının değişmesi gereken kayıtların kimliklerinin bir listesi verilirse, kendinize güncellemenin program bağlamında neden yapıldığını sormalısınız. Bu güncelleme gereken 10 kayıtların, tablo sadece olabilir sahiptir 10 unsurları. Bu nedenle, kendinize kavramsal olarak yaptığınız her şeyin tüm kayıtların durumunu güncelleyip güncellemediğini sormalısınız.

Ekleyebiliyorsanız, tercih edilir.

Kayıt ekleme eylemi bağımsızdır. Bununla kastedilen bir kayıt eklemenin sadece bir yan etkisi vardır ve bu daha önce var olmayan bir kaydın varlığıdır. Bu nedenle, orada olmaması gereken bir kayıt eklemezseniz, hiçbir sorun olmamalıdır.

Silme işleminden kaçınabiliyorsanız, tercih edilir.

Bir silme işlemi gerçekleştiriyorsanız, aksi takdirde yedek olmadan kurtarılamayacak verileri kaldırırsınız. Mümkünse, verileri, kaydı fiziksel olarak silmek yerine durumunu değiştirerek devre dışı bırakabilecek şekilde düzenlemeye çalışın. Fazla veri bir bölüme konabilir veya sorun olmadığından emin olduktan sonra daha sonra tamamen kaldırılabilir.

Tutarlı bir güncelleme politikasına sahip olun.

Bir kaydı güncellemeniz gerekiyorsa, birkaç şeyden biri olabilir:

1. Kaydınız mevcut değil.
2. Kaydınız var, ancak zaten değiştirildi.
3. Kaydınız var ve değişiklik gerekiyor.

Bir şeyin planlandığı gibi gitmemesi durumunda eylemin gidişatını belirlemek için bir politikanız olmalıdır. Kolaylık olması açısından, genel olarak tutarlı olmanız ve bu politikayı yalnızca belirli tablolar için değil, bu türden herhangi bir durumda uygulamanız gerekir . Bu, verileri daha sonra kurtarmayı kolaylaştırır. Genel olarak, politikam komut dosyasını daha sonra yeniden yürütebilecek şekilde yazmaktır. Betik başarısız olursa, uygun ayarlamaları yapabileceğinizi ve yeniden çalıştırabileceğinizi bilmek güzeldir, ancak size en uygun politikayı seçmekte özgürsünüz.

Yedekler

Bu hiçbir şekilde üretim ortamında herhangi bir güncelleme yapmadan önce bir yedekleme yapmanıza izin vermez! Bir yedeklemede bile olsa, yedeklemeyi kullanmak zorunda kalmamayı düşünüyorum. En kötü senaryoda bile veri kaybı olasılığı yoktur .

Sonuç

Her zaman istediğin gibi elde edemezsin. Tablo şemasının sizin tarafınızdan belirlenmesi muhtemel değildir ve bu nedenle gerçekleştirmeyi bekleyebileceğiniz güncelleme türleri hem karmaşık hem de riskli olacaktır. Konuyla ilgili herhangi bir sözünüz varsa da, herhangi bir güncellemeyi doğrudan ve önemli bir risk olmadan yaptıkları için bu noktaları akılda tutmaya yardımcı olur.

İyi şanslar!

Bu noktada, anlık görüntüleri destekleyen bir ticari sınıf DB sistemi kullanmalısınız (Oracles, Flashback olarak adlandırılır ) - tam olarak bu tür şeyler için.

Yine de bir yedekleme konseptine ihtiyacınız olduğunu unutmayın - daha fazla veriye sahip olmak yedekleri bıraktığınız anlamına gelmez, çünkü zorlaşırlar, tam tersi. Örneğin, otomatik yük devretme ile çoğaltmaya dayalı olarak bir tür sürekli yedekleme yapmanız gerekir.

Bu muazzam bir alandır - bu sorunun oldukça kısa bir sırada kapatılmasını bekleyin, ancak başımın üstünden (yuge veritabanlarında eski bir DBA olarak):

Mart / Depo

Güncellemeler için ayrı bir veritabanı ve herkesin kullandığı ayrı bir veritabanı varsa, bazı riskleri azaltabilirsiniz. Ardından, çeşitli kontroller yapıldıktan sonra verilerin bir DB'den diğerine kopyalanması durumudur. Mart / depo bazen nasıl tanımlandığıdır, ancak birincil / ikincil, master / slave vb.

Kaynak kodu

Değişebilen her şey için , verilerin nasıl güncellendiğiyle ilgili bir kaynak koduna sahip olun . Bunlardan kaç tanesi DB'den DB'ye değişir ancak her kullanıcı, rol, veri feed'i, kod modülü vb. İçin bir tane olabilir.

Tarih oluştur / güncelle

İşlerin yanlış gittiğini takip ederken büyük ölçüde yardımcı olabilecek bir şey, her satır için bir oluşturma ve güncelleme verisine sahip olmaktır. Ardından hangi satırların güncellendiğini bir bakışta görebilirsiniz.

ETL

Veritabanı güncellemesi bir veri fabrikasının parçası olarak yer alıyorsa, önceki bir eski şablonu düz dosyalardan geri yükleyebilirsiniz.

yedek

Tam yedeklemeler elbette çok yer kaplar, ancak olağan senaryo, düzenli aralıklarla (haftalık, haftalık) tam bir yedeklemenin ve daha sık (günlük vb.)

Zamanında kurtarma

Hangi RDBMS'yi kullandığınıza bağlı olarak, zaman kurtarmada bazı destek noktaları. Bu, iyi bir durumun bilindiği zamana geri dönmenizi sağlar. Ancak bu, geri gitmek istediğinizde artan büyük miktarda depolama alanı gerektirir.

Denetim

Denetim tablolarına sahip olmak, bir satıra kimin (veya neyin) güncelleme yaptığını söyleyecektir. Bu size araştırma için iyi bir başlangıç ​​noktası sağlayabilir.

Tarihçe

Bazı kritik tablolar için, güncelleme sırasında ilgili satırın bir kopyası alınır, böylece gerekirse veriler geri yüklenebilir.

Veri doğrulama

Temel veri türü kontrollerinin üzerinde ve üstünde saklanmadan önce veriler üzerinde temel doğrulama kontrollerinin yapıldığından emin olun.

Bilgi tutarlılığı

Referans bütünlüğü gümüş bir madde değildir, ancak verilerin iyi yapılandırılmasını sağlamaya yardımcı olabilir.

Çoğu zaman "tek seferlik" bir güncelleme yapıyorsak, prodüksiyonu yedekler ve test sunucusuna geri yükleriz. Sonra bir takım testler hazırlıyoruz ve tek atış gerçekleştiriyoruz. Verilerin testler yoluyla değiştiğini doğrularız ve güncellemenin başarılı olacağı konusunda rahat olur ve verileri beklediğimiz şekilde değiştiririz. Buna kuru çalışma veya deneme sürüşü denir. Bunu yapmanızı tavsiye ederim.

Bu, herkese bir vuruşun başarılı olacağı konusunda iyi bir fikir verir. Veriler deneme sürümü tarihinden itibaren güncelleneceğinden% 100 garanti edemeyiz, ancak güven ve başarı faktörlerini artırıyoruz. Bu aynı zamanda üretimin bir kopyasını kullandığımızdan bu yana ortaya çıkacak herhangi bir sorun hakkında gerçek bir fikir verir. Şimdi bir nedenden dolayı güncelleme başarısız olursa, gerektiğinde geri yüklemeden önce her zaman geri çalışmaya gidebiliriz, ancak kuru çalışma ile ilgili herhangi bir sorunu bulup düzeltmeliydik.

Veritabanının tamamını (gerçekten büyükse) alamazsanız, daha küçük bir örnek boyutu vermeyi deneyin ve güncellemeyi (küçük kuru çalışma) gerçek verilere karşı çalıştırın. Testin mümkün olduğunca eksiksiz olmasını sağlamak için mümkünse tüm veri kümesini tercih ederim.