Apa praktik yang Anda ikuti untuk menghindari pembaruan data yang salah di database besar?


20

Saran khas sebelum penyebaran produksi adalah cadangan DB terlebih dahulu. Dengan cara ini, jika pembaruan baru memiliki beberapa masalah yang dapat menyebabkan kehilangan data potensial atau kerusakan data logis, maka Anda masih memiliki cadangan untuk membandingkan dan memperbaiki catatan lama.

Namun, ini dapat bekerja dengan baik hingga ukuran DB dalam beberapa GB. Setelah ukuran DB sangat besar, pencadangan membutuhkan waktu lama. Apa saja praktik terbaik yang harus diikuti dalam situasi seperti itu, sehingga untuk menghindari korupsi data logis karena masalah logis dalam penyebaran kode?


11
Cadangan tidak hanya untuk saat Anda melakukan penyebaran. Maksud saya, kehilangan data Anda hanya satu disk-crash jauh, dan itu tidak dapat diprediksi dan dapat terjadi hari ini atau besok. (Array serangan bukan jawabannya, mereka juga crash.)
Pieter B

10
Saya akan mengulangi pertanyaan ini, masalahnya bukan bahwa pencadangan memerlukan waktu lama, masalahnya adalah jika pembaruan mengalami kegagalan yang parah, pemulihan mungkin diperlukan, yang dapat memblokir produksi untuk waktu yang lama. Jadi apa yang benar-benar Anda cari adalah strategi untuk mengurangi risiko kegagalan selama pembaruan.
Doc Brown

1
Saya setuju dengan @DocBrown di sini. Menghindari korupsi data dan pencadangan yang terlalu lama sebenarnya adalah dua pertanyaan terpisah.
Robbie Dee

1
Ketika Anda menerima dengan cepat, Anda tidak mendapatkan banyak input.
paparazzo

1
Apa maksud Anda "masalah logis dalam penyebaran kode"?
paparazzo

Jawaban:


25

Sebagai seseorang yang secara teratur berurusan dengan memperbarui basis data produksi untuk pelanggan untuk peningkatan perangkat lunak kami, saya memberitahu Anda bahwa cara terbaik untuk meminimalkan kesalahan adalah dengan membuat pembaruan sesederhana mungkin.

Jika Anda dapat melakukan perubahan untuk semua catatan daripada catatan tertentu, itu lebih disukai.

Dengan kata lain, jika Anda diberi daftar id dari catatan yang perlu diubah keadaannya, Anda harus bertanya pada diri sendiri mengapa pembaruan dilakukan dalam konteks program. Mungkin dari 10 catatan yang perlu Anda perbarui, tabel hanya memiliki 10 elemen. Karena itu Anda harus bertanya pada diri sendiri apakah secara konseptual semua yang Anda lakukan adalah memperbarui status semua catatan.

Jika Anda dapat menyisipkan, itu lebih disukai.

Tindakan menambahkan catatan mandiri. Maksud saya hanya ada satu efek samping dari menambahkan catatan, dan itu adalah keberadaan catatan yang tidak ada sebelumnya. Karena itu, kecuali Anda menambahkan catatan yang seharusnya tidak ada di sana, seharusnya tidak ada masalah.

Jika Anda dapat menghindari penghapusan, itu lebih disukai.

Jika Anda melakukan penghapusan, Anda menghapus data yang seharusnya tidak dapat dipulihkan tanpa cadangan. Jika memungkinkan, cobalah untuk mengatur data sedemikian rupa sehingga Anda dapat menonaktifkan catatan dengan mengubah kondisinya daripada menghapus catatan secara fisik. Kelebihan data dapat diletakkan di partisi atau dapat dihapus seluruhnya di lain waktu setelah Anda yakin tidak ada masalah.

Memiliki kebijakan pembaruan yang konsisten.

Jika Anda perlu memperbarui catatan, salah satu dari beberapa hal dapat terjadi:

  1. Catatan Anda tidak ada.
  2. Catatan Anda ada tetapi sudah diubah.
  3. Catatan Anda ada dan membutuhkan perubahan.

Anda perlu memiliki kebijakan untuk menentukan arah tindakan jika sesuatu tidak berjalan sesuai rencana. Demi kesederhanaan, Anda harus konsisten di seluruh papan dan menerapkan kebijakan ini dalam situasi apa pun dari jenis ini, tidak hanya untuk tabel tertentu. Ini membuatnya lebih mudah untuk dapat memulihkan data nanti. Secara umum, kebijakan saya adalah menulis skrip sedemikian rupa agar dapat menjalankannya kembali nanti. Jika skrip gagal, senang mengetahui bahwa Anda dapat melakukan penyesuaian dan eksekusi ulang yang tepat, namun Anda bebas memilih kebijakan sendiri yang paling sesuai untuk Anda.

Cadangan

Ini tidak berarti memaafkan Anda untuk melakukan pencadangan sebelum melakukan pembaruan apa pun di lingkungan produksi! Meskipun dengan cadangan, saya menganggapnya gagal menggunakan cadangan. Kehilangan data tidak dapat menjadi kemungkinan bahkan dalam skenario terburuk .

Kesimpulan

Anda tidak selalu bisa melakukannya sesuai keinginan Anda. Skema tabel kemungkinan tidak akan ditentukan oleh Anda, dan karena itu artinya jenis pembaruan yang dapat Anda lakukan akan rumit dan berisiko. Meskipun jika Anda memiliki hak suara dalam masalah ini, ada baiknya Anda mengingat poin-poin ini saat mereka melakukan pembaruan secara langsung dan tanpa risiko yang signifikan.

Semoga berhasil!


Saya setuju dengan semua yang Anda katakan, tetapi saya ingin tahu tentang pemikiran Anda tentang transaksi ketika ada 10 catatan yang perlu diganti dari 10k dan memasukkan / memperbarui semua catatan tidak layak?
Saya di sini untuk Winter Hats

Maka Anda hanya memperbarui 10 catatan. Saya katakan jika Anda bisa, lakukanlah. Saya tidak mengatakan melakukannya bahkan jika itu menghancurkan basis data produksi pelanggan Anda. Mohon saran saya dengan sebutir garam.
Neil

12

Pada titik itu, Anda harus menggunakan sistem DB kelas komersial yang mendukung snapshot (Oracles menyebutnya Flashback ) - itulah jenisnya.

Ingatlah bahwa Anda memerlukan konsep cadangan - memiliki lebih banyak data tidak berarti Anda menjatuhkan cadangan karena menjadi sulit, justru sebaliknya. Anda memerlukan semacam cadangan berkelanjutan, misalnya berdasarkan replikasi dengan failover otomatis.


Saya tidak mengatakan saya ingin menjatuhkan cadangan. Backup terjadwal selalu ada. Pertanyaannya lebih lanjut tentang cadangan ad-hoc, yang tidak masalah adalah sistem kecil.
Pritam Barhate

Untuk menguraikan lebih jauh, garis pemikiran ini berasal dari NoSQL DB sebagai platform Layanan. Sebenarnya sedang membaca dokumentasi Firestore, ketika muncul. Jika Anda memerlukan cadangan yang konsisten secara logis di luar kantor, sepertinya sangat mahal. Jadi saya bertanya-tanya bagaimana tim produk yang sukses bekerja dengan sistem seperti itu dan bagaimana mereka memastikan bahwa korupsi data logis tidak terjadi.
Pritam Barhate

@PritamBarhate: Anda tidak perlu "lebih banyak cadangan" karena pembaruan. Pada basis data produksi tempat orang bekerja dengan data itu, cadangan harus dilakukan setidaknya setiap hari, dengan atau tanpa pembaruan. Kembalikan adalah masalah Anda, Anda ingin menghindari pemulihan yang tidak perlu dalam semua keadaan.
Doc Brown

3
Replikasi dengan failover otomatis adalah redundansi tidak lebih merupakan strategi cadangan untuk database daripada menggunakan RAID untuk disk .
Blrfl

1
Semua poin bagus tentang backup dan snapshot, tetapi membersihkan operasi database yang gagal (jika beberapa jam data baru telah ditambahkan sebelum direalisasikan) bisa sangat sulit tergantung pada skenario dan sistem lain yang memengaruhi (penjadwalan, entri basis data lainnya) yang bergantung padanya, jika membentang beberapa tabel, cache, otentikasi, dll). Saya selalu berasumsi bahwa saya harus menggunakan cadangan, tetapi selalu setidaknya mencoba untuk tidak perlu melakukannya.
Penguin Anonim

3

Ini adalah area yang sangat luas - jadi perkirakan pertanyaan ini akan ditutup dalam waktu yang cukup singkat tetapi, dari atas kepala saya (sebagai mantan DBA pada database besar):

Mart / Repositori

Anda dapat mengurangi beberapa risiko jika Anda memiliki database terpisah untuk pembaruan dan database terpisah yang digunakan semua orang. Maka itu hanya kasus menyalin data dari satu DB ke yang lain setelah berbagai pemeriksaan telah terjadi. Mart / repositori adalah bagaimana kadang-kadang dijelaskan tetapi Anda mungkin memiliki primer / sekunder, master / slave dll.

Kode sumber

Untuk semua yang dapat berubah, miliki kode sumber yang terkait dengan cara data diperbarui. Berapa banyak dari ini yang Anda miliki bervariasi dari DB ke DB tetapi Anda mungkin memiliki satu untuk setiap pengguna, peran, umpan data, modul kode dll.

Buat / perbarui tanggal

Sesuatu yang dapat sangat membantu saat melacak kesalahan yang terjadi adalah memiliki pembuatan dan pembaruan data untuk setiap baris. Kemudian Anda dapat melihat sekilas baris mana yang telah diperbarui.

ETL

Jika pembaruan database mengambil bagian sebagai bagian dari pabrik data, Anda mungkin dapat memulihkan vintage sebelumnya dari file datar.

Cadangkan

Cadangan penuh tentu saja membutuhkan banyak ruang tetapi skenario yang biasa adalah agar pencadangan penuh terjadi secara berkala (misalnya, mingguan) dan sebagian lagi secara lebih teratur (harian, dll).

Titik pemulihan waktu

Tergantung pada RDBMS yang Anda gunakan, beberapa titik dukungan dalam pemulihan waktu. Ini memungkinkan Anda untuk kembali ke masa ketika kondisi baik diketahui. Namun ini membutuhkan sejumlah besar penyimpanan yang meningkatkan sejauh mana Anda ingin kembali.

Audit

Memiliki tabel audit akan memberi tahu Anda siapa (atau apa) yang melakukan pembaruan pada satu baris. Ini bisa memberi Anda titik awal yang baik untuk investigasi.

Sejarah

Untuk beberapa tabel kritis, salinan baris terkait diambil pada saat pembaruan sehingga data dapat dipulihkan jika perlu.

Validasi data

Pastikan pemeriksaan validasi dasar dilakukan pada data sebelum disimpan - di atas dan di atas pemeriksaan tipe data dasar.

Integritas referensial

Integritas referensial bukan peluru perak tetapi dapat membantu memastikan data terstruktur dengan baik.



2

Sering kali jika kita melakukan pembaruan "satu tembakan", kita mengambil cadangan produksi dan mengembalikannya ke server uji. Kemudian kami membuat serangkaian tes dan menjalankan satu tembakan. Kami memverifikasi data telah berubah melalui tes dan merasa nyaman bahwa pembaruan itu akan berhasil dan memodifikasi data dengan cara yang kami harapkan. Ini disebut run kering atau percobaan. Saya sarankan melakukan ini.

Ini memberi setiap orang perasaan yang baik bahwa satu tembakan akan berhasil. Kami tidak dapat menjamin 100% karena data akan diperbarui sejak tanggal uji coba, tetapi kami meningkatkan faktor kepercayaan dan kesuksesan. Ini juga memberikan gambaran nyata tentang masalah apa pun yang akan terjadi karena kami menggunakan salinan produksi. Sekarang jika karena suatu alasan pembaruan gagal, kita selalu dapat kembali ke menjalankan sebelum mengembalikan jika diperlukan, tetapi kita harus menemukan dan memperbaiki masalah dengan menjalankan kering.

Jika Anda tidak dapat mengambil seluruh database (jika benar-benar besar) coba dan ekspor ukuran sampel yang lebih kecil dan jalankan pembaruan (lari kering kecil) terhadap data aktual. Saya lebih suka seluruh kumpulan data jika memungkinkan untuk memastikan tes selengkap mungkin.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.