Cara menyimpan data pada mesin yang kekuatannya terputus secara acak

13

Saya memiliki mesin virtual (Debian) yang berjalan di host mesin fisik. Mesin virtual bertindak sebagai penyangga untuk data yang sering diterima melalui jaringan lokal (periode untuk data ini adalah 0,5s, sehingga throughput yang cukup tinggi). Setiap data yang diterima disimpan di mesin virtual dan berulang kali diteruskan ke server eksternal melalui UDP. Setelah server eksternal mengakui (lebih dari UDP) bahwa ia telah menerima paket data, data asli dihapus dari mesin virtual dan tidak dikirim ke server eksternal lagi. Koneksi internet yang menghubungkan VM dan server eksternal tidak dapat diandalkan, artinya bisa turun selama berhari-hari.

Mesin fisik yang meng-host VM mendapatkan pemadaman listriknya beberapa kali per hari secara acak. Tidak ada cara untuk mengetahui kapan ini akan terjadi dan tidak mungkin untuk menambahkan UPS, baterai, atau solusi serupa ke sistem.

Awalnya, data disimpan pada basis data HSQLDB berbasis file di mesin virtual. Namun, pemadaman listrik yang sering pada akhirnya menyebabkan file skrip database menjadi rusak (tidak pada tingkat sistem file, yaitu dapat dibaca, tetapi HSQLDB tidak dapat memahaminya), yang mengarah ke pertanyaan saya:

Bagaimana seharusnya data disimpan di lingkungan di mana pemadaman listrik dapat dan memang sering terjadi?

Satu pilihan yang bisa saya pikirkan adalah menggunakan file flat, menyimpan setiap paket data sebagai file pada sistem file. Dengan cara ini jika suatu file rusak karena kehilangan daya, itu dapat diabaikan dan sisa data tetap utuh. Ini menimbulkan beberapa masalah Namun, terutama terkait dengan jumlah data yang kemungkinan disimpan di mesin virtual. Pada 0,5s antara setiap bagian data, 1.728.000 file akan dihasilkan dalam 10 hari. Ini setidaknya berarti menggunakan sistem file dengan peningkatan jumlah inode untuk menyimpan data ini (pengaturan sistem file saat ini kehabisan inode pada ~ 250.000 pesan dan 30% ruang disk yang digunakan). Juga, sulit (bukan tidak mungkin) untuk dikelola.

Apakah ada opsi lain? Apakah ada mesin basis data yang berjalan pada Debian yang tidak akan rusak oleh pemadaman listrik? Juga, sistem file apa yang harus digunakan untuk ini? ext3 adalah apa yang digunakan saat ini.

Perangkat lunak yang berjalan pada mesin virtual ditulis menggunakan Java 6, jadi semoga solusinya tidak akan kompatibel.

debian filesystems corruption

— Seva
sumber

14

"Mesin fisik yang menjadi tuan rumah VM mendapatkan pemadaman listriknya beberapa kali per hari secara acak. Tidak ada cara untuk mengetahui kapan ini akan terjadi dan tidak mungkin untuk menambahkan UPS, baterai, atau solusi serupa ke sistem." Saya benar - benar ingin tahu bagaimana itu mungkin. Apakah itu di Stasiun Luar Angkasa Internasional sehingga memerlukan $ 20 juta untuk mengirim UPS atau sesuatu?

— ceejayoz

3

Apakah mesin setidaknya memiliki pengontrol RAID dengan cache yang didukung baterai?

— Zoredache

4

Kami dapat merekomendasikan solusi yang sangat menarik, kreatif, dan mungkin secara teoritis benar untuk masalah ini. Namun , kita tidak tahu hypervisor dan perangkat keras apa yang berjalan pada host, jadi tidak akan ada jaminan bahwa penulisan disk benar-benar ditulis, atau ditulis dalam urutan yang benar ...

— pino42

5

@Sevas Kedengarannya itu bukan panggilan Anda, tetapi saya sarankan untuk menunjukkan bahwa 50 UPS dasar yang murah akan berharga $ 2500, dan tidak perlu pemeliharaan (Anda menggantinya setelah beberapa tahun ketika baterai mulai menyala ). Biaya mencoba menyelesaikan ini dalam perangkat lunak akan jauh lebih tinggi dari itu, kecuali Anda tahu banyak coders yang bekerja secara gratis. Mungkin akan membantu untuk mendapatkan manajemen untuk menyelesaikan ini untuk $ 50 / unit, daripada puluhan atau ratusan jam kerja terampil @ 3-angka per jam.

— HopelessN00b

9

Ini sebenarnya terdengar seperti program jahat. Pengguna tidak tahu "VM" berjalan di komputer mereka. Ini mencuri data dari seluruh jaringan - kemudian menyalurkannya melalui satu koneksi untuk menyembunyikan diri. Pengguna "mematikan dan menghidupkan komputer" secara acak - sehingga Anda tidak dapat menambahkan UPS.

— Laurence

23

Jujur pendekatan terbaik Anda di sini adalah untuk memperbaiki pemadaman listrik, atau menggunakan sistem yang berbeda di lokasi yang lebih baik.

Ya ada sistem seperti redis yang akan menyimpan data dalam log tambahan-tambahan untuk replay, tetapi Anda berisiko korupsi pada tingkat yang lebih rendah - misalnya jika sistem file Anda diacak maka data pada disk berpotensi berisiko.

Saya menghargai setiap perbaikan akan bermanfaat bagi Anda, tetapi sebenarnya masalahnya bukan salah satu yang dapat dipecahkan mengingat skenario yang telah Anda uraikan.

8

+1 Jawaban yang benar adalah "Jangan lakukan itu"

— Chris S

6

+1 Akhirnya, pemadaman listrik acak akan merusak sistem file Anda. Elektronik melakukan hal-hal aneh yang tidak dapat diprediksi karena kekuatan mereka gagal.

— Grant

-1 (virtual -1). Saya pikir sistem seperti itu harus dibangun dengan asumsi bahwa pemadaman listrik terjadi dari waktu ke waktu. Asumsi ini adalah fakta dunia nyata yang harus Anda tangani.

— Igal Serban

11

Pendekatan Anda bisa berhasil. Izinkan saya menyarankan beberapa peningkatan untuk itu. Ada pertanyaan dalam stack overflow pada penulisan atom ke file . Pada dasarnya Anda menyimpan setiap paket data ke file sementara dan kemudian Anda menamainya menjadi nama akhirnya. Mengganti nama adalah operasi atom yang akan aman dari kegagalan daya. Dengan begitu Anda dijamin bahwa semua file Anda di tujuan akhir Anda telah disimpan dengan benar tanpa korupsi.

Lalu apa yang dapat Anda lakukan untuk menangani masalah memiliki jutaan file. Adalah cron pekerjaan yang berjalan mungkin setiap jam yang mengambil semua file lebih lama dari satu jam dan menggabungkannya menjadi satu file besar menggunakan operasi file atom lagi sehingga pekerjaan ini berjalan dengan aman bahkan selama listrik mati, dan kemudian menghapus file lama. Jenis rotasi log seperti. Nilai satu jam file akan menjadi sekitar 7.200 file. Jadi kapan saja Anda seharusnya tidak memiliki lebih dari 20.000 file pada disk.

— Marwan Alsabbagh
sumber

1

Bukan jawaban yang buruk, tetapi masalahnya adalah dengan menganggap bahwa penulisan itu sendiri adalah operasi atom, padahal bukan. Jadi kegagalan daya pada waktu yang salah masih bisa membuat data atau korupsi FS. Mungkin tentang opsi terbaik pendek memperbaiki daya, atau menghubungkannya ke UPS, jadi +1.

— HopelessN00b

Pengubahan nama

— Marwan Alsabbagh

Ya, mengganti nama file yang pernah ditulis adalah operasi atom. Menulis file di tempat pertama, bukan.

— HopelessN00b

3

@ HopelessN00b Tidak masalah bahwa file baru setengah tertulis atau rusak. Anda memiliki file lama yang dalam kondisi baik. Ketika Anda memulihkan sistem, Anda menghancurkan file setengah tertulis.

— DJClayworth

2

@ HopelessN00b Persis! hanya file sementara dalam direktori sementara yang memungkinkan hanya setengah ditulis. Semua file di direktori tujuan akhir Anda akan selalu non-korup dan aman di disk

— Marwan Alsabbagh

7

Anda memasang UPS atau kartu RAID dengan cache tulis yang didukung baterai ke sistem, dan hanya dengan $ 49,95 , Anda mencapai apa yang tidak mungkin dicapai dalam perangkat lunak saja.

Klaim Anda bahwa entah bagaimana tidak mungkin menghubungkan server ini ke UPS atau baterai ... sama sekali tidak dapat dipercaya.

— HopelessN00b
sumber

9

Kebodohan birokratis selalu bisa dipercaya.

— Dan sedang mengutak-atik Firelight

3

@DanNeely My PHB won't let me hook this up to a UPS/batteryadalah hal yang sangat berbeda dari it is not possible to add a UPS, a battery, or a similar solution to the system. Tidak menjadi terlalu berlebihan, tetapi ini merupakan perbedaan penting karena mengubah pendekatan dan solusi yang tersedia.

— HopelessN00b

Atau, seperti yang disebutkan di tempat lain, pengguna komputer yang dibajak akan terkejut jika saya meminta untuk memasang UPS. Situasi agak sulit dipercaya sebaliknya. Siapa pun akan, dengan alasan, menerima UPS atas data yang rusak karena kasus bisnis yang tepat.

— WernerCD

@WernerCD Saya ingin Anda memenuhi CIO kami. Meskipun saya setuju bahwa membajak komputer seseorang adalah kasus penggunaan yang mungkin untuk ini, saya bisa memikirkan yang sah juga, jadi saya akan memberi orang itu keuntungan dari keraguan itu. Pikirkan tentang sistem dan pengendali yang disematkan, atau seperti Raspberry Pi - bisa dipastikan bahwa "komputer" yang Anda gunakan bernilai kurang dari $ 50 yang diperlukan untuk memasangnya ke UPS.

— HopelessN00b

Bahkan jika komputer bernilai kurang dari $ 50 UPS - itu adalah data pada komputer yang sebenarnya bernilai sesuatu. Google dibangun di atas komputer "tidak berharga". Lebih penting daripada biaya CPU adalah biaya kehilangan data, kehilangan tenaga manusia (Petualangan pemrograman ini, pengejaran korupsi data, pelacakan bug di sistem lama serta bagian baru ini), kehilangan nilai pelanggan (Kehilangan data saya? Perusahaan berikutnya, silakan.), Dll.

— WernerCD

5

Pasang seluruh sistem hanya-baca, kecuali untuk perangkat blok yang menyimpan semua data Anda. Gunakan perangkat blok itu secara langsung dan terapkan mekanisme penyimpanan data Anda sendiri menggunakan perangkat blok mentah itu.

— MikeyB
sumber

3

... dan berinvestasi dalam kartu pengontrol disk yang didukung baterai, dan pastikan tidak ada cache tulis pada disk, atau Anda masih kacau.

— voretaq7

Datang ke sini untuk mengatakan mereka harus mem-boot off dari Live-CD atau sistem ROM yang setara, dengan beberapa penyimpanan solid state digunakan dengan solusi flat file.

— Mark Allen

Tembolok tulis dapat dinonaktifkan. Pendekatan ini layak. Tambahkan hanya Mekanisme penyimpanan yang disarankan. Blok ditulis secara atomik (saya berasumsi) sehingga Anda dapat memiliki dua blok "penunjuk" yang menunjuk ke awal dan akhir bagian dengan data baru / todo. Pointer diperbarui setelah menulis / menyelesaikan data. NCQ juga harus dinonaktifkan.

— sleeplessnerd