Halo semuanya!
Beberapa waktu yang lalu, saya terjun ke dunia "perusahaan keras", yaitu di daerah itu yang bertanggung jawab untuk menyimpan dan membuat cadangan data. Lebih tepatnya, di dalamnya yang paling. Dan selama periode ini saya telah mengumpulkan beberapa aturan yang saya coba patuhi ketika merancang atau melayani solusi di bidang ini. Beberapa sudah hidup lebih lama dari mereka sendiri, dengan perkembangan teknologi, dan beberapa cukup bekerja. Dan saya memutuskan untuk membagikannya kepada Anda.
Tidak akan ada aturan 3-2-1, yang sering disebutkan tanpa saya, serta beberapa teknik langsung untuk situasi tertentu dan hal-hal lain dalam nada yang sama. Mungkin bagi sebagian besar dari mereka yang membaca ini akan menjadi dasar dan kata-kata hampa. Ini hanya pengalaman saya yang sederhana dan saya harap ini akan bermanfaat bagi seseorang. Saya minta kucing.
Fitur "ukuran" lokal
Cepat atau lambat, ada kebutuhan untuk mendapatkan lebih banyak terabyte dan / atau IOPS. Dan kemudian ukuran dimulai. Seringkali tidak berarti dan tanpa ampun. Karena sangat jarang seseorang menetapkan persyaratan RTO untuk ukuran, yang biasanya disajikan untuk cadangan. Meskipun sepertinya persyaratan yang jelas untuk setiap kompleks perangkat keras. Yaitu Saat menentukan ukuran dan membentuk persyaratan untuk peralatan baru, untuk beberapa alasan, persyaratan sistem cadangan, yang akan segera mengembalikan sesuatu ke perangkat keras Anda, tidak diperhitungkan. Terkadang ada sesuatu yang cukup besar. Secara umum, beberapa jenis margin produktivitas dan ruang diletakkan, tetapi pemulihan data pertama menunjukkan bahwa itu tidak akan cukup untuk siklus hidup yang ditentukan untuk peralatan ini.
Selama setahun terakhir, saya telah melihat situasi dua kali ketika kemacetan selama pemulihan data adalah array disk tempat pemulihan dilakukan. Mereka cocok dengan RTO, tapi belnya mengkhawatirkan.
Kami memiliki solusi pada kluster, mengapa Anda perlu cadangan ?!
Ini adalah ungkapan yang diucapkan dengan "penuh semangat" yang saya dengar ketika berkomunikasi
dengan pengembang satu perangkat lunak yang sangat berguna untuk satu bisnis. Pengembang berpendapat bahwa cadangan tidak perlu untuk pemulihan oleh fakta bahwa solusi tersebut digunakan pada sebuah cluster dan oleh karena itu, jika sebuah node (atau array disk) jatuh di situs, cluster tersebut akan disimpan. Dalam kasus ini, dia pasti akan menyelamatkan. Ini umumnya sangat baik ketika ada beberapa orang yang berpikir tentang toleransi kesalahan bahkan pada tahap pengembangan.
Namun, kehilangan data dicapai tidak hanya oleh kegagalan peralatan di satu situs, dan karena alasan tertentu pengembang tidak ingin memahami ini untuk beberapa waktu. Akibatnya, versi pertama dari perangkat lunak dirilis pada DBMS komunitas, mekanisme cadangan yang tidak memungkinkan untuk memenuhi persyaratan RTO / RPO atau SLA dari kontraktor.
Secara umum, saya sering mendengar frasa ini tentang sebuah cluster.
Pertama, lalu ini!
Salah satu kesalahan terbesar saya adalah mempertimbangkan objek cadangan sebagai yang independen. Ini DBMS, ini software-nya. Ini cadangan seperti ini, dan ini seperti itu. Yang pertama, lalu yang lain. Dan suatu hari kami tidak bisa pulih. Lebih tepatnya, mereka bisa, tetapi selama beberapa hari dihabiskan untuk memperbaiki kesalahan dalam database. Dan bukan saya yang melenyapkan mereka, yang membuat saya sangat malu. Meskipun kami menggunakan mekanisme cadangan reguler untuk DBMS ini. Sudah diuji pada sistem lain.
Sejak saat itu, saya mendorong hidung saya dan mengguncang pengembang / pemilik sistem tentang masalah cara membuat cadangan dan memulihkan dengan benar. Misalnya, dalam satu kasus, satu-satunya cara untuk membuat cadangan yang berfungsi adalah dengan sepenuhnya menghentikan layanan di 5 server, membuat cadangan, dan memulai layanan.
Dump semuanya?
Seringkali saya menemukan solusi pada DBMS seperti MySQL dan PostgreSQL. Dan bahkan lebih sering saya menemukan situasi di mana pembuangan dangkal database di / tmp digunakan sebagai metode cadangan, dan kemudian ke media lain. Pada saat yang sama, sistem di mana DBMS ini digunakan sangat penting untuk downtime jika terjadi kehilangan data, dan sangat dimuat. Saya sudah diam tentang volume.
Untuk beberapa alasan, beberapa orang membaca dokumentasi untuk produk ini dan tidak tahu bahwa ada metode dan solusi alternatif untuk membuat cadangan dari DBMS ini.
MySQL Enterprise Backup untuk MySQL dan
pg_basebackup (
pg_start_backup, pg_stop_backup ) masing-masing di PostgreSQL. Atau dia tahu, tetapi terbang keluar dari kepalanya. Meskipun solusi ini tidak jauh lebih rumit dan lebih cepat. Cadangan lebih cepat, pemulihan lebih cepat, tes lebih cepat.
Tolong jangan menembak pianis.
Dia melakukan yang terbaik.
Oscar Fingal O'Flahertie Wills Wilde