💿 🐠 🉑 Buku “Database. Rekayasa Keandalan 👩🏼‍🏫 😢 👩🏽‍🌾

Halo, habrozhiteli! Di bidang IT, sebuah revolusi nyata terjadi - mereka mulai bekerja dengan infrastruktur seperti halnya dengan kode. Proses ini tidak hanya menciptakan masalah baru, tetapi juga peluang untuk memastikan uptime basis data. Para penulis telah menyiapkan panduan praktis ini bagi siapa saja yang ingin bergabung dengan komunitas insinyur keandalan database modern (DBRE).

Dalam buku ini: • persyaratan penyimpanan dan persyaratan manajemen risiko. • Pembuatan dan pengembangan arsitektur yang menyediakan dukungan database transparan. • merampingkan proses manajemen rilis. • penyimpanan, pengindeksan dan replikasi data. • menentukan karakteristik gudang data dan memilih opsi terbaik untuk penggunaannya. • penelitian komponen arsitektur dan penciptaan arsitektur yang berorientasi pada pemrosesan data besar.

Untuk siapa buku ini?

, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

Struktur publikasi

. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

Cadangkan & Kembalikan

Dalam bab 5 dan 6, kami fokus pada perancangan dan pengelolaan infrastruktur. Ini berarti Anda memiliki ide bagus tentang cara membuat dan menggunakan infrastruktur terdistribusi tempat database bekerja, serta mengelolanya. Kami melihat metode untuk dengan cepat menambahkan node baru untuk meningkatkan kapasitas atau mengganti node yang gagal. Sekarang saatnya membahas hal yang paling penting - mencadangkan dan memulihkan data.

Mari kita hadapi itu: semua orang mempertimbangkan untuk mendukung dan memulihkan kegiatan yang membosankan dan membosankan. Bagi sebagian besar, prosedur ini adalah lambang rutin. Tim tidak suka berinteraksi dengan insinyur junior dan kontraktor eksternal dan bekerja dengan alat pihak ketiga. Sebelumnya, kami harus berurusan dengan perangkat lunak cadangan yang mengerikan. Kami bersimpati dengan Anda, jujur.

Namun demikian, ini adalah salah satu proses terpenting dalam pekerjaan Anda. Memindahkan data penting antara node, pusat data, dan mentransfernya ke arsip jangka panjang adalah pergerakan konstan aset paling berharga dari bisnis Anda - informasi. Kami sangat menyarankan agar Anda tidak menganggap operasi pemulihan dan cadangan sebagai operasi kelas dua, tetapi memperlakukannya sebagai operasi VIP. Setiap orang tidak hanya harus memahami tujuan pemulihan data, tetapi juga memahami prinsip-prinsip pekerjaan ini dan memantau proses. Filosofi DevOps mengasumsikan bahwa setiap orang harus dapat menulis kode dan mengimplementasikannya dalam sistem yang benar-benar berfungsi. Kami mengundang setiap insinyur untuk mengambil bagian dalam proses pemulihan data kritis setidaknya sekali.

Kami membuat dan menyimpan salinan data - cadangan dan arsip - sebagai cara untuk memenuhi kebutuhan tertentu. Mereka diperlukan untuk pemulihan. Kadang-kadang pemulihan adalah urusan yang menyenangkan dan santai, misalnya, ketika menciptakan lingkungan untuk auditor atau menyiapkan lingkungan alternatif. Tetapi paling sering diperlukan untuk mengganti node gagal dengan cepat atau meningkatkan kapasitas cluster yang ada.

Hari ini, di lingkungan terdistribusi, kami menghadapi tantangan baru dalam pencadangan dan pemulihan data. Seperti sebelumnya, sebagian besar set data lokal didistribusikan dalam batas wajar, hingga maksimum beberapa terabyte. Perbedaannya adalah bahwa set data lokal ini hanya bagian dari set terdistribusi besar. Pemulihan situs adalah proses yang relatif terkendali, tetapi mempertahankan keadaan dalam sebuah cluster adalah tugas yang lebih sulit.

Prinsip dasar

Kami mulai dengan membahas prinsip dasar pencadangan dan pemulihan data. Untuk seorang spesialis basis data yang berpengalaman atau insinyur sistem, beberapa dari mereka mungkin tampak dasar. Jika demikian, Anda dapat dengan mudah menggulir beberapa halaman.

Fisik atau logis?

Cadangan fisik database membuat cadangan file nyata tempat data disimpan. Ini berarti bahwa format file tipikal dari database didukung, dan biasanya ada satu set metadata dalam database yang menentukan file apa dan struktur database apa yang ada di dalamnya. Jika, saat membuat salinan cadangan file, Anda mengharapkan instance database lain untuk dapat menggunakannya, maka Anda perlu membuat cadangan dan menyimpan metadata yang terkait dengannya, yang menjadi sandaran basis data ini, sehingga cadangan tersebut portabel.

Saat membuat cadangan logis, data diekspor dari database ke format yang secara teoritis dapat ditransfer ke sistem apa pun. Biasanya metadata juga disimpan, tetapi kemungkinan besar itu akan relevan untuk saat ketika cadangan dilakukan. Contohnya adalah ekspor semua pernyataan sisipan yang diperlukan untuk mengisi basis data kosong saat memperbaruinya. Contoh lain adalah string JSON. Akibatnya, pencadangan logis, sebagai suatu peraturan, memerlukan banyak waktu, karena ini bukan operasi penyalinan dan penulisan fisik, tetapi ekstraksi data baris demi baris. Demikian pula, pemulihan disertai dengan semua overhead database yang biasa, seperti mengunci dan membuat redo dan batalkan log.

Sebuah contoh yang bagus dari pemisahan ini adalah perbedaan antara replikasi berbasis baris dan replikasi berbasis pernyataan. Dalam banyak basis data relasional, replikasi berbasis agen berarti bahwa setelah menulis ke sistem kontrol versi, jurnal operator bahasa manipulasi data (DML, atau menyisipkan, memperbarui, mengganti, menghapus) ditambahkan ke dalamnya. Pernyataan-pernyataan ini diteruskan ke replika di mana mereka diputar. Pendekatan lain untuk replikasi didasarkan pada string atau Change Data Capture (CDC).

Otonom atau operasional?

Cadangan offline (atau dingin) adalah cadangan di mana instance database menggunakan file dinonaktifkan. Berkat ini, Anda dapat dengan cepat menyalin file tanpa khawatir mempertahankan status saat ini, sementara proses lain membaca dan menulis data. Ini adalah kondisi yang ideal, tetapi sangat jarang.

Dengan cadangan online (atau panas), Anda masih menyalin semua file, tetapi ada kompleksitas tambahan yang terkait dengan kebutuhan untuk mendapatkan snapshot data yang konsisten, yang harus ada pada waktu itu saat cadangan dilakukan. Selain itu, jika lalu lintas saat ini mengakses database selama cadangan, Anda harus berhati-hati untuk tidak melebihi throughput dari subsistem I / O di tingkat penyimpanan. Bahkan membatasi beban, Anda mungkin menemukan bahwa mekanisme yang digunakan untuk menjaga konsistensi menimbulkan penundaan yang tidak masuk akal dalam aplikasi.

Penuh, inkremental, dan diferensial

Memiliki cadangan lengkap, apa pun metode yang dibuat, berarti set data lokal sepenuhnya dicadangkan. Untuk dataset kecil, ini sangat umum. Untuk 10 TB, ini bisa menghabiskan banyak waktu.

Pencadangan diferensial memungkinkan Anda hanya mencadangkan data yang telah berubah sejak pencadangan penuh terakhir. Namun dalam praktiknya, lebih banyak data biasanya dicadangkan dari sekadar yang diubah, karena data disusun dalam bentuk struktur dengan ukuran tertentu - halaman. Ukuran halaman, misalnya, 16 atau 64 Kbytes, dan halaman tersebut berisi banyak baris data. Backup diferensial membuat cadangan semua halaman tempat data telah diubah. Jadi, dengan ukuran halaman yang besar, cadangan dengan ukuran yang jauh lebih besar diperoleh daripada jika hanya data yang dimodifikasi yang disimpan di sana.

Cadangan inkremental mirip dengan cadangan diferensial, kecuali bahwa tanggal pencadangan terakhir yang merujuk data yang diubah adalah inkremental atau penuh. Jadi, ketika memulihkan dari cadangan inkremental, Anda mungkin perlu mengembalikan cadangan penuh terakhir, serta satu atau lebih cadangan inkremental, untuk sampai ke titik saat ini.

Mengetahui hal ini, kita akan membahas beberapa poin yang harus dipertimbangkan ketika memilih strategi pencadangan dan pemulihan data yang efektif.

Pertimbangan Pemulihan Data

Ketika memilih strategi yang efektif untuk pertama kalinya, Anda harus mempertimbangkan lagi target kualitas layanan Anda (SLO), yang dibahas dalam Bab 2. Secara khusus, Anda perlu mempertimbangkan indikator ketersediaan dan keandalan. Apa pun strategi yang Anda pilih pada akhirnya, itu harus tetap mencakup kemampuan untuk memulihkan data dalam batas waktu yang ditentukan sebelumnya. Dan Anda harus membuat cadangan dengan cepat untuk memastikan kepatuhan dengan spesifikasi keandalan Anda.

Jika Anda membuat cadangan setiap hari dan menyimpan log transaksi di antara cadangan di penyimpanan di tingkat situs, Anda dapat dengan mudah kehilangan transaksi ini hingga cadangan berikutnya.

Selain itu, Anda perlu mempertimbangkan bagaimana set data berfungsi dalam ekosistem holistik. Misalnya, pesanan Anda dapat disimpan dalam basis data relasional, di mana semuanya ditetapkan dalam bentuk transaksi dan, karenanya, mudah dipulihkan terkait dengan data lain yang disimpan dalam basis data ini. Namun, setelah pesanan terbentuk, alur kerja dapat dipicu oleh peristiwa yang disimpan dalam sistem antrian atau penyimpanan tipe "nilai kunci". Sistem ini dapat memastikan integritas data hanya sesekali atau bahkan secara singkat (untuk sementara), merujuk, jika perlu, ke database relasional atau menggunakannya untuk pemulihan. Bagaimana cara mempertimbangkan alur kerja ini selama pemulihan?

Jika Anda berurusan dengan lingkungan di mana perkembangan pesat sedang berlangsung, mungkin ternyata data yang disimpan dalam cadangan ditulis dan digunakan oleh satu versi aplikasi, dan setelah memulihkan yang lain dijalankan. Bagaimana aplikasi berinteraksi dengan data yang sudah usang? Nah, jika datanya diversi- kan, maka ini bisa diperhitungkan, tetapi Anda harus mewaspadai kemungkinan ini dan bersiaplah untuk kasus seperti itu. Jika tidak, aplikasi secara logis dapat merusak data ini, yang akan menyebabkan masalah yang lebih besar di masa depan.

Semua ini dan banyak nuansa lain yang tidak dapat diprediksi harus dipertimbangkan ketika merencanakan pemulihan data. Sebagaimana dinyatakan dalam Bab 3, tidak mungkin untuk bersiap menghadapi situasi apa pun. Tetapi sangat penting untuk mencoba melakukannya. Pemulihan data adalah salah satu tugas paling penting dari seorang insinyur untuk memastikan keandalan basis data. Dengan demikian, rencana pemulihan data Anda harus seluas mungkin dan memperhitungkan sebanyak mungkin masalah yang mungkin terjadi.

Skenario Pemulihan

Setelah memperhitungkan semua hal di atas, kami akan membahas jenis insiden dan operasi yang mungkin memerlukan pemulihan data sehingga semua kebutuhan dapat direncanakan. Pertama, Anda dapat membagi semua skenario menjadi terencana dan tidak terencana. Mengingat pemulihan data hanya sebagai alat untuk menyelesaikan keadaan darurat, Anda akan membatasi alat tim Anda hanya untuk perawatan darurat dan mensimulasikan kecelakaan. Sebaliknya, jika pemulihan data termasuk dalam kegiatan sehari-hari, tingkat kesadaran yang lebih tinggi dan penyelesaian darurat yang sukses dapat diharapkan. Selain itu, kami akan memiliki lebih banyak data untuk menentukan apakah strategi pemulihan mendukung SLO kami. Dengan beberapa skrip harian, akan lebih mudah untuk mendapatkan satu set sampel,yang mencakup nilai batas dan yang dapat digunakan dengan cukup percaya diri untuk perencanaan.

Skenario Pemulihan Terjadwal

Apa tugas sehari-hari yang dapat dipadukan dengan proses pengembalian? Berikut adalah daftar yang paling sering kami temui di berbagai situs:

penciptaan node dan cluster baru di lingkungan operasi industri;
penciptaan berbagai lingkungan;
melakukan ekstraksi, transformasi, dan pemuatan (Extract, Transform and Load, ETL) dan tahapan proses teknologi pemrosesan data untuk penyimpanan yang ditempatkan secara berurutan;
pengujian kinerja.

Saat melakukan operasi ini, pastikan untuk memasukkan proses pemulihan pada tumpukan kontrol operasional. Pertimbangkan indikator berikut.

Waktu. Berapa lama untuk menyelesaikan setiap komponen dan seluruh proses? Membongkar? Salinan? Eksekusi log? Pengujian?
Ukuran. Berapa banyak ruang yang dibutuhkan cadangan, terkompresi, dan tidak terkompresi?
. ?

Informasi ini akan membantu Anda menghindari masalah bandwidth, yang akan membantu memastikan stabilitas proses pemulihan.

Node dan Cluster Baru dalam Lingkungan Operasi Industri

Apakah database Anda merupakan bagian dari infrastruktur yang tidak berubah atau tidak, ada peluang untuk pembangunan kembali secara berkala, di mana prosedur pemulihan akan digunakan sesuai kebutuhan.

Basis data jarang dimasukkan dalam penskalaan otomatis sistem karena jumlah waktu yang mungkin diperlukan untuk pemuatan awal node baru dan penempatannya dalam sebuah cluster. Namun demikian, tidak ada alasan mencegah tim dari membuat jadwal untuk secara teratur menambahkan node baru ke cluster untuk menguji proses ini. Chaos Monkey ( http://bit.ly/2zy1qsE) - alat yang dikembangkan oleh Netflix yang mematikan sistem secara acak, memungkinkan Anda melakukan ini sedemikian rupa sehingga Anda dapat menguji seluruh proses pemantauan, mengeluarkan pemberitahuan, menyortir, dan memulihkan. Jika Anda belum melakukannya, Anda dapat memasukkan ini dalam rencana untuk daftar periksa proses yang harus dilakukan departemen operasi Anda secara berkala sehingga semua karyawan menjadi terbiasa dengan prosedur tersebut. Tindakan ini memungkinkan Anda untuk menguji tidak hanya pemulihan penuh dan inkremental, tetapi juga inklusi replikasi dan proses menempatkan node ke dalam operasi.

Buat lingkungan yang berbeda

Anda pasti akan menciptakan lingkungan pengembangan, integrasi, dan pengujian operasional untuk demonstrasi dan tujuan lain. Beberapa lingkungan ini memerlukan pemulihan data penuh, dan mereka perlu menerapkan pemulihan simpul dan pemulihan cluster penuh. Beberapa lingkungan memiliki persyaratan lain, seperti dukungan pemulihan parsial untuk pengujian fitur dan pembersihan data untuk memastikan privasi pengguna. Ini memungkinkan Anda untuk menguji pemulihan data pada titik waktu tertentu, serta pemulihan objek tertentu. Semua ini sangat berbeda dari pemulihan penuh standar dan berguna untuk memperbaiki kerusakan yang disebabkan oleh tindakan operator dan kesalahan aplikasi. Dengan membuat API,yang menyediakan pemulihan data di tingkat fasilitas dan pada titik waktu tertentu, Anda dapat memfasilitasi otomatisasi dan pengenalan karyawan dengan proses-proses ini.

ETL dan proses pipa untuk gudang data yang terletak jauh di bawah pipa.

Sedangkan untuk tugas membangun lingkungan, proses dan API pemulihan dari snapshot atau pada tingkat objek individu dapat berhasil diterapkan ketika mentransfer data dari database produksi ke pipa untuk analisis lebih lanjut dan untuk mengalirkan penyimpanan .

Pengujian Lapangan

Selama pelaksanaan berbagai skenario pengujian, Anda akan memerlukan salinan data. Beberapa pengujian, misalnya untuk kapasitas dan beban, memerlukan set data lengkap, yang bagus untuk pemulihan penuh. Pengujian fungsional mungkin memerlukan kumpulan data yang lebih kecil, yang akan memungkinkan pemulihan pada titik waktu tertentu dan pada tingkat fasilitas.

Pengujian pemulihan data itu sendiri dapat menjadi operasi yang berkelanjutan. Selain menggunakan proses pemulihan data dalam skenario sehari-hari, Anda dapat mengonfigurasi operasi pemulihan berkelanjutan. Ini akan mengotomatiskan pengujian dan validasi untuk dengan cepat mengidentifikasi masalah yang mungkin timbul jika proses pencadangan terganggu. Ketika datang untuk menerapkan proses ini, banyak yang bertanya bagaimana memverifikasi keberhasilan pemulihan.

Saat membuat cadangan, Anda bisa mendapatkan banyak data yang dapat Anda gunakan untuk pengujian, misalnya:

Pengidentifikasi terbaru dalam urutan kenaikan-otomatis
penghitung garis untuk objek;
checksum untuk himpunan bagian data yang hanya dimasukkan dan karenanya dapat dianggap tidak dapat diubah;
checksum dalam file definisi skema.

Seperti halnya pengujian apa pun, pendekatannya harus bertingkat. Ada sejumlah tes yang akan berhasil atau gagal dengan cepat. Ini harus menjadi pengujian tingkat pertama. Contohnya adalah membandingkan checksum untuk definisi metadata / objek, berhasil memulai instance database, dan berhasil menyambung ke aliran replikasi. Operasi yang mungkin memakan waktu lebih lama, seperti menghitung checksum dan tabel penghitungan, harus dilakukan kemudian selama pemeriksaan.

Skrip yang tidak direncanakan

Dengan mempertimbangkan semua skenario harian yang direncanakan yang dapat digunakan, proses pemulihan data harus didebug dengan baik, didokumentasikan, dikerjakan dan cukup bebas dari kesalahan dan masalah. Berkat ini, skenario yang tidak terencana jarang berubah menjadi menakutkan seperti yang mereka bisa. Tim seharusnya tidak melihat perbedaan antara pemulihan yang direncanakan dan yang tidak direncanakan. Kami mendaftar dan mempertimbangkan dalam situasi terperinci yang mungkin mengharuskan kami untuk melakukan proses pemulihan:

kesalahan pengguna
aplikasi error;
ketersediaan layanan infrastruktur;
kesalahan sistem operasi dan kesalahan perangkat keras;
kegagalan perangkat keras;
kegagalan pusat data.

Kesalahan pengguna Idealnya, kesalahan pengguna jarang terjadi. Dengan membangun "pagar" dan "penghalang" untuk insinyur, Anda dapat mencegah banyak dari situasi ini. Namun, selalu ada kemungkinan bahwa operator akan secara tidak sengaja menyebabkan kerusakan. Contoh tipikal adalah di mana-mana dan untuk semua klausa WHERE yang dilupakan ketika menjalankan UPDATE atau DELETE dalam aplikasi klien basis data. Atau, misalnya, pelaksanaan skrip pembersihan data tidak dalam lingkungan uji, tetapi dalam sistem "produksi" yang berfungsi. Seringkali operasi dilakukan dengan benar, tetapi pada waktu yang salah atau tidak untuk host tersebut. Semua ini berkaitan dengan kesalahan pengguna. Seringkali mereka diidentifikasi dan diperbaiki segera. Namun, terkadang konsekuensi dari perubahan tersebut tidak diperhatikan selama beberapa hari atau minggu.

Kesalahan aplikasi

Kesalahan aplikasi adalah skenario terburuk yang dibahas, karena mereka bisa sangat berbahaya. Aplikasi terus mengubah cara mereka berinteraksi dengan gudang data. Banyak aplikasi juga mengelola integritas referensial dan pointer eksternal ke sumber daya seperti file atau pengidentifikasi pihak ketiga. Menakutkan membayangkan apa yang akan terjadi jika Anda hanya membuat perubahan yang merusak data, menghapusnya atau menambahkan data yang salah dengan cara yang tidak diketahui selama beberapa waktu.

Layanan Infrastruktur

Dalam Bab 6, kami memperkenalkan keajaiban layanan manajemen infrastruktur. Sayangnya, sistem ini dapat berubah menjadi sama merusaknya dengan berguna, yang dapat menyebabkan konsekuensi skala besar terkait dengan mengedit file, menunjuk ke lingkungan lain atau pengaturan konfigurasi yang salah.

Kesalahan OS dan kesalahan perangkat keras

Sistem operasi dan peralatan yang berinteraksi dengannya juga merupakan sistem yang dibuat oleh orang, dan dengan demikian kesalahan dapat terjadi pada mereka yang dapat memiliki konsekuensi yang tidak terduga karena konfigurasi tidak terdokumentasi atau kurang dikenal. Dalam konteks pemulihan data, ini terutama benar sehubungan dengan cara data ditransfer dari database melalui cache OS ke sistem file, pengontrol, dan akhirnya ke disk. Kerusakan atau kehilangan data terjadi jauh lebih sering daripada yang kita pikirkan. Sayangnya, kepercayaan dan ketergantungan kita pada mekanisme ini memunculkan ekspektasi integritas data alih-alih skeptisisme tentangnya.

Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

Kegagalan

perangkat keras Komponen perangkat keras pada prinsipnya gagal, dan dalam sistem terdistribusi ini terjadi secara teratur. Anda terus-menerus mengalami kegagalan disk, memori, prosesor, pengontrol, dan perangkat jaringan. Konsekuensi dari kegagalan perangkat keras ini dapat berupa kegagalan node atau keterlambatan pada node, yang membuat sistem tidak dapat digunakan. Sistem bersama, seperti perangkat jaringan, dapat memengaruhi seluruh cluster, membuatnya tidak dapat diakses atau memecahnya menjadi cluster yang lebih kecil yang tidak sadar bahwa jaringan telah dibagi. Ini dapat menyebabkan perbedaan yang cepat dan signifikan dalam data yang perlu digabungkan dan diperbaiki.

Kegagalan Pusat Data

Terkadang masalah perangkat keras di tingkat jaringan menyebabkan crash di pusat data. Itu terjadi bahwa overloading backplanes penyimpanan menyebabkan kegagalan cascading, seperti halnya dengan layanan web Amazon pada 2012 ( http://bit.ly/2zxSpzR ). Kadang-kadang badai, gempa bumi, dan bencana lainnya menyebabkan kegagalan seluruh pusat data. Pemulihan selanjutnya akan menguji bahkan strategi pemulihan yang paling andal untuk kekuatan.

Ruang lingkup skrip

Setelah menghitung skenario yang direncanakan dan tidak terencana yang mungkin memerlukan pemulihan, kami menambahkan satu dimensi lagi untuk peristiwa ini sehingga presentasi kami menjadi sangat banyak. Ini akan berguna untuk memilih metode respons yang paling tepat. Pertimbangkan opsi berikut:

kegagalan terlokalisasi dalam satu simpul tunggal;
kegagalan seluruh cluster;
Kegagalan yang memengaruhi seluruh pusat data atau beberapa kluster.

Dalam hal kegagalan lokal, atau satu situs, pemulihan terbatas pada satu host. Anda dapat menambahkan node baru ke cluster untuk meningkatkan kapasitas atau mengganti node yang gagal. Atau, sistem mengimplementasikan pembaruan terus-menerus dan kemudian pemulihan akan dilakukan simpul demi simpul. Bagaimanapun, ini adalah pemulihan lokal.

Pada tingkat cluster, kebutuhan untuk pemulihan bersifat global untuk semua anggota cluster ini. Mungkin ada perubahan destruktif atau penghapusan data yang mengalir ke semua node. Atau Anda perlu memperkenalkan kluster baru untuk menguji kapasitas.

Jika ada kegagalan pada skala pusat data atau beberapa cluster, itu berarti bahwa perlu untuk mengembalikan semua data di tempat lokasi fisik mereka atau di seluruh area kegagalan. Ini mungkin disebabkan oleh kegagalan gudang data bersama atau kegagalan yang menyebabkan kegagalan besar pusat data. Pemulihan semacam itu juga mungkin diperlukan selama rencana penempatan situs sekunder baru.

Selain ruang lingkup, ada ruang lingkup dataset. Di sini Anda dapat membuat daftar tiga opsi yang mungkin:

satu objek;
beberapa benda;
metadata basis data.

Pada skala satu objek, hanya objek khusus ini yang memerlukan pemulihan data - sebagian atau semua. Kasus yang dibahas sebelumnya, sebagai akibatnya ketika operasi DELETE dilakukan, lebih banyak data dihapus daripada yang direncanakan, mengacu pada kegagalan dalam objek yang sama. Jika beberapa objek gagal, beberapa atau, mungkin, semua objek dalam database tertentu terpengaruh. Ini dapat terjadi jika aplikasi rusak, pembaruan atau migrasi segmen gagal. Akhirnya, ada crash pada skala metadata database ketika semuanya sesuai dengan data yang disimpan dalam database, tetapi metadata hilang yang membuatnya dapat digunakan, seperti data pengguna, hak istimewa keamanan, atau kepatuhan dengan file OS.

Konsekuensi skrip

Penting tidak hanya untuk mengidentifikasi skenario yang membutuhkan pemulihan dan untuk mengidentifikasi area kegagalan, tetapi juga untuk menentukan konsekuensi yang mungkin, karena mereka akan signifikan ketika memilih pendekatan untuk pemulihan. Jika kehilangan data tidak memengaruhi SLO, Anda dapat memilih pendekatan metodis dan lambat yang meminimalkan perluasan konsekuensi. Perubahan yang lebih global yang mengarah pada gangguan SLO harus didekati dengan hati-hati, memilih pemulihan layanan yang cepat dan hanya kemudian beralih ke pembersihan jangka panjang. Semua pendekatan dapat dibagi menjadi tiga kategori berikut.

Dampak pada SLO, kegagalan aplikasi, mempengaruhi sebagian besar pengguna.
Ancaman SLO, beberapa pengguna menderita.
Fungsi yang tidak mengancam SLO terpengaruh.

Tentang Penulis

Campbell Lane (Laine Campbell) adalah manajer senior (Direktur Senior) untuk perusahaan desain Fastly. Dia juga pendiri dan CEO PalominoDB / Blackbird, layanan konsultasi yang mengelola basis data untuk beberapa perusahaan, termasuk Obama untuk Amerika, Activision Call of Duty, Adobe Echosign, Technorati, Livejournal, dan Zendesk. Dia memiliki 18 tahun pengalaman mengoperasikan basis data dan sistem terdistribusi yang dapat diskalakan.

Jurusan Kehormatan(Charity Majors) adalah CEO dan salah satu pendiri honeycomb.io. Menggabungkan keakuratan agregator log, metrik kecepatan deret waktu, dan fleksibilitas Metrik Kinerja Aplikasi (APM), honeycomb adalah layanan analitik generasi benar-benar baru di dunia. Charity sebelumnya adalah spesialis operasi Parse / Facebook, mengelola armada besar set replika MongoDB, serta Redis, Cassandra, dan MySQL. Dia juga bekerja erat dengan tim RocksDB di Facebook, berpartisipasi dalam pengembangan dan penyebaran instalasi Mongo + Rocks pertama di dunia menggunakan plug-in storage API.

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Untuk diskon 25% Khabrozhiteley pada kupon - Database

Setelah pembayaran versi kertas buku, sebuah buku elektronik dikirim melalui email.

Buku “Database. Rekayasa Keandalan