Rumah > Artikel > pangkalan data > Mari kita bincangkan mengapa anda tidak perlu bergantung pada ketersediaan tinggi MySQL untuk penyelenggaraan
Kos masa henti dalam persekitaran perusahaan meningkat dengan cepat. Dalam satu tinjauan, 40% daripada responden berkata bahawa hanya satu jam masa henti memerlukan organisasi mereka melebihi $1 juta. Adalah jelas berbaloi untuk memastikan perkhidmatan pangkalan data sentiasa tersedia.
Ia menjimatkan banyak wang organisasi anda, apatah lagi hubungan dengan pemegang kepentingan dalam semua bentuk dan saiz.
Jadi bagaimana anda memastikan ketersediaan berterusan? Konsep di sebalik ketersediaan berterusan dipanggil Ketersediaan Tinggi . Dalam artikel ini, kami akan memberikan gambaran keseluruhan tentang ketersediaan tinggi dan cara melaksanakannya untuk kluster MySQL anda.
Kami juga menunjukkan sisi gelap ketersediaan tinggi, walaupun apabila pentadbir sistem tersilap bergantung pada ketersediaan tinggi untuk melaksanakan tugas penyelenggaraan - dan terangkan sebab berbuat demikian mengalahkan matlamat ketersediaan tinggi dan meletakkan operasi perniagaan anda dalam risiko.
Mari bincangkan tentang ketersediaan dahulu. Tidak ada gunanya menjalankan perkhidmatan (seperti pangkalan data) jika ia tidak tersedia kepada pengguna pada kebanyakan masa. Oleh itu, apabila kita bercakap tentang ketersediaan, kami maksudkan betapa mudahnya perkhidmatan itu.
Dengan mana-mana perkhidmatan yang berjalan dengan betul, seseorang boleh menjangkakan ia akan sentiasa tersedia apabila diperlukan - tetapi juga akan ada masa henti, satu atau dua hari setahun, atau beberapa jam sebulan .
Perkhidmatan yang tersedia secara umum mungkin bagus untuk banyak senario kes penggunaan, tetapi jika perkhidmatan itu bersifat kritikal, atau sebilangan besar pengguna bergantung pada perkhidmatan, bergantung pada "ketersediaan" sahaja tidak mencukupi. .
Inilah maksud ketersediaan tinggi. Pada asasnya, ketersediaan yang tinggi memastikan tahap ketersediaan yang lebih tinggi daripada yang biasanya dijangkakan dan, lebih khusus lagi, tahap yang dipersetujui, membenarkan penyelenggaraan, penampalan dan ralat dan kegagalan umum.
Tiada definisi yang dipersetujui tentang ketersediaan tinggi, hanya untuk memenuhi keperluan ketersediaan tertentu (lebih tinggi), yang biasanya melebihi apa yang diterima sebagai "ketersediaan" oleh pembekal. Malah, organisasi anda mungkin mentakrifkan ketersediaan yang diperlukan berdasarkan keperluan operasi anda - menimbang kos ketersediaan yang tinggi berbanding kos kerugian berkaitan masa henti.
Tahap ketersediaan yang anda perlukan boleh dinyatakan sebagai peratusan. Sebagai contoh, ketersediaan 99.99% atau "empat sembilan" bermaksud maksimum 52.06 minit masa henti dalam setahun, manakala "enam sembilan" atau 99.9999% ketersediaan mengehadkannya kepada 31.56 minit masa henti dalam setahun.
Pada asasnya, pilihan di tangan anda - tetapi, sekali lagi, ia adalah satu pertukaran. Mengekalkan ketersediaan tinggi akan menjadi mahal - memerlukan sumber fizikal tambahan dan lesen perisian, dan menguras sumber manusia anda. Walau bagaimanapun, anda mungkin mendapati ia adalah harga yang patut dibayar untuk mengelakkan kos gangguan atau risiko kehilangan hasil akibat pelanggan yang tidak berpuas hati.
Sifat tepat infrastruktur ketersediaan tinggi anda bergantung pada beban kerja anda. Walau bagaimanapun, secara amnya, ketersediaan tinggi dicapai apabila terdapat toleransi kesalahan, supaya walaupun satu perkhidmatan atau peranti gagal, beban kerja tidak terganggu. Biasanya, ini bermakna tiada titik kegagalan tunggal - semua perkhidmatan dan peranti berlebihan sepenuhnya pada peringkat rangkaian dan aplikasi.
Bergantung pada perkhidmatan, ini biasanya melibatkan beberapa nod - contohnya, kluster MySQL anda akan mengandungi beberapa nod lagi yang mana data disimpan. Berbilang nod kemudiannya digabungkan dengan alat pengimbangan beban supaya jika satu nod gagal, permintaan diarahkan ke nod lain. Pengguna masih boleh mengakses perkhidmatan yang tersedia, walaupun prestasinya merosot sedikit.
Sudah tentu, laluan anda ke pangkalan data MySQL yang sangat tersedia akan bergantung pada pelaksanaan MySQL anda. Secara ringkasnya, anda perlu mencipta beberapa jenis kluster MySQL dengan berbilang nod - dengan kata lain, data anda mesti disimpan pada berbilang pelayan MySQL.
Seterusnya, anda memerlukan perkhidmatan yang boleh meniru data pada nod ini, memastikan setiap nod mempunyai salinan tepat data yang terkandung dalam pangkalan data anda. Akhir sekali, anda memerlukan pengimbang beban untuk memastikan bahawa sebarang permintaan pangkalan data diarahkan sama rata ke nod pangkalan data - ya, beban seimbang - tetapi pastikan bahawa walaupun satu nod di luar talian, permintaan itu dipenuhi.
Sebagai contoh, MySQL menyediakan produk komersial untuk ketersediaan tinggi - Te MySQL InnoDB Cluster. Ia berdasarkan Replikasi Kumpulan MySQL, cara popular untuk memastikan ketersediaan tinggi dalam persekitaran pangkalan data MySQL.
Alternatif lain ialah Galera, yang telah menyediakan ketersediaan tinggi MySQL selama bertahun-tahun. Jika anda menggunakan garpu MariaDB MySQL, anda boleh mengkonfigurasi persekitaran MariaDB anda untuk ketersediaan tinggi dengan menjalankan berbilang nod pada kluster Galera anda - sambil bergantung pada HAProxy untuk pengimbangan beban. Sebagai alternatif, anda juga boleh melihat produk MaxScale
MariaDB sendiri. 5. Sebab yang baik untuk bergantung pada ketersediaan tinggi…
6 … dan sebab yang salah untuk bergantung pada ketersediaan tinggi
Malangnya, peningkatan populariti ketersediaan tinggi telah menyebabkan penyalahgunaannya. Oleh kerana ketersediaan tinggi menjadikan sistem sangat teguh, pasukan teknikal mungkin tergoda untuk mengambil jalan pintas semasa melaksanakan tugas pengurusan sistem (seperti menampal) kerana pasukan tersebut percaya bahawa infrastruktur ketersediaan tinggi hanya akan menanggung beban untuk membawa mesin ke luar talian.Sebenarnya, ia menjadi lebih rumit dengan cepat. Ambil MySQL Cluster sebagai contoh. Ya, jika anda but semula mesin untuk menampalnya, kluster MySQL anda akan terus berjalan kerana ketersediaan yang tinggi. Walau bagaimanapun, perlu diingat bahawa apabila anda menutup nod untuk menampal dan kemudian memulakannya semula, ia mewujudkan tunggakan data yang perlu dimasukkan. Proses ini mungkin mengambil masa yang lama untuk diselesaikan.
Tidak perlu dikatakan, setiap hos pangkalan data perlu melihat data yang sama. Bahaya datang daripada proses penyegerakan semula: jika nod lain rosak semasa anda telah menutup dan menampalnya, ini boleh mengakibatkan kehilangan kuorum sah terakhir. Dalam erti kata lain, bilangan pelayan yang memegang "kebenaran" tentang data mungkin lebih rendah daripada tahap yang boleh diterima. Pemulihan daripada keadaan ini boleh menjadi sukar dan kompleks, malah boleh mengakibatkan kehilangan data.
7 Jangan bergantung pada ketersediaan tinggi untuk penyelenggaraan
#Sebaliknya, pasukan teknikal harus bergantung pada penyelesaian lain - contohnya, menyediakan redundansi penuh untuk sistem yang sedang ditampal, dan bukannya hanya berharap bahawa infrastruktur ketersediaan tinggi dapat menahan tekanan. Sebagai alternatif, jika boleh,
bergantung pada tampalan masa nyata sebaliknya, dengan itu menghapuskan keperluan untuk memulakan semula perkhidmatan untuk memasang tampalan. Walau bagaimanapun, pergantungan pada ketersediaan yang tinggi untuk kerja penyelenggaraan menunjukkan tanda yang membimbangkan. Lihat dengan teliti dan anda juga akan mendapat panduan rasmi daripada vendor yang mengarahkan pengguna untuk bergantung pada ketersediaan tinggi untuk melaksanakan tugas menampal. Pengguna hanya berharap apabila satu nod pergi ke luar talian untuk menampal, nod lain tidak menghadapi sebarang masalah.
Ketersediaan tinggi adalah penting untuk banyak aplikasi - dan bermanfaat kepada banyak aplikasi lain. Dikonfigurasikan dengan betul, pangkalan data MySQL boleh menyediakan ketersediaan yang hampir sempurna, tetapi itu tidak bermakna pasukan teknikal boleh mengambil mudah ketersediaan.
Menyalahgunakan seni bina ketersediaan tinggi untuk mengekalkan pintasan penyelenggaraan adalah tidak digalakkan - risikonya lebih besar daripada yang kelihatan pada pandangan pertama.
Sebaliknya, pentadbir sistem harus mencari alternatif yang terbukti - termasuk redundansi dan tampalan langsung - untuk melaksanakan operasi penyelenggaraan tanpa menjejaskan keupayaan penyelesaian ketersediaan tinggi.
Alamat asal: https://tuxcare.com/understanding-mysql-high-availability-good-and-bad-reasons-to-use-it/
Alamat terjemahan : https://learnku.com/mysql/t/71681
[Cadangan berkaitan: tutorial video mysql]
Atas ialah kandungan terperinci Mari kita bincangkan mengapa anda tidak perlu bergantung pada ketersediaan tinggi MySQL untuk penyelenggaraan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!