Artikel ini membawakan anda pengetahuan yang berkaitan tentang mysql, yang terutamanya memperkenalkan isu yang berkaitan dengan penyelesaian ketersediaan tinggi biasa Di sini kita hanya membincangkan kelebihan dan kekurangan penyelesaian ketersediaan tinggi biasa dan ketersediaan tinggi melihat pilihan penyelesaian saya harap ia akan membantu semua orang.
Pembelajaran yang disyorkan: tutorial video mysql
Kami sedang mempertimbangkan ketersediaan MySQL yang tinggi pangkalan data Semasa mereka bentuk seni bina, kita harus mempertimbangkan aspek berikut:
Kami tidak akan membincangkan klasifikasi ketersediaan tinggi secara terperinci di sini Kami hanya akan membincangkan kebaikan dan keburukan penyelesaian ketersediaan tinggi yang biasa digunakan dan pemilihan penyelesaian ketersediaan tinggi.
Gunakan pangkalan data dua nod untuk membina sehala atau dua- cara replikasi separa segerak. Dalam versi selepas 5.7, pengenalan siri ciri baharu seperti replikasi tanpa kehilangan dan replikasi berbilang benang logik menjadikan replikasi separa segerak asli MySQL lebih dipercayai.
Seni bina biasa adalah seperti berikut:
Ia biasanya digunakan bersama dengan perisian pihak ketiga seperti proksi dan keepalived, yang boleh digunakan untuk memantau kesihatan pangkalan data dan melaksanakan satu siri arahan pengurusan. Jika pangkalan data utama gagal, pangkalan data masih boleh digunakan selepas bertukar kepada pangkalan data siap sedia.
Kelebihan:
2.2. Pengoptimuman replikasi separa segerak
Semi. -masa replikasi segerak kerana Selepas itu, replikasi terputus apabila replikasi ditubuhkan semula, dua saluran ditubuhkan pada masa yang sama Salah satu saluran replikasi separa segerak mula mereplikasi dari kedudukan semasa untuk memastikan hamba mengetahui. kemajuan pelaksanaan hos semasa. Satu lagi saluran replikasi tak segerak mula mengejar data hamba yang ketinggalan. Apabila saluran replikasi tak segerak mengejar kedudukan permulaan replikasi separa segerak, replikasi separa segerak disambung semula.
Seni binanya mudah, tiada masalah untuk memilih induk, hanya beralih terus Berbanding dengan replikasi asli, Replikasi separa segerak yang dioptimumkan boleh memastikan ketekalan data dengan lebih baik.
Kelemahan:
Perlu mengubah suai kod sumber kernel atau menggunakan protokol komunikasi mysql. Anda perlu mempunyai pemahaman tertentu tentang kod sumber dan dapat melakukan tahap pembangunan sekunder tertentu.
Masih bergantung pada replikasi separa segerak, yang secara asasnya tidak menyelesaikan masalah ketekalan data.
2.3. Pengoptimuman seni bina ketersediaan tinggi
Disebabkan replikasi separa segerak, terdapat ciri bahawa replikasi separa segerak dianggap berjaya apabila respons yang berjaya daripada hamba diterima Oleh itu, kebolehpercayaan replikasi separa segerak berbilang hamba adalah lebih baik daripada kebolehpercayaan replikasi separa segerak hamba tunggal. Selain itu, kebarangkalian berbilang nod turun pada masa yang sama adalah kurang daripada kebarangkalian satu nod turun Oleh itu, pada tahap tertentu, seni bina berbilang nod boleh dianggap mempunyai ketersediaan tinggi yang lebih baik daripada dwi-nod seni bina.
Namun, disebabkan bilangan pangkalan data yang banyak, perisian pengurusan pangkalan data diperlukan untuk memastikan kebolehselenggaraan pangkalan data. Anda boleh memilih MMM, MHA atau pelbagai versi proksi, dsb. Penyelesaian biasa adalah seperti berikut:
Pengurus MHA akan mengesan nod induk dalam gugusan secara berkala . Apabila tuan muncul Sekiranya berlaku kegagalan, ia secara automatik boleh mempromosikan hamba dengan data terkini kepada tuan baharu, dan kemudian mengalihkan semua hamba lain kepada tuan baharu Keseluruhan proses failover adalah telus sepenuhnya kepada aplikasi.
MHA Node berjalan pada setiap pelayan MySQL Fungsi utamanya adalah untuk memproses log binari semasa pertukaran untuk memastikan penukaran meminimumkan kehilangan data.
MHA juga boleh dilanjutkan kepada kluster berbilang nod berikut:
Kelebihan:
boleh mengesan dan memindahkan kerosakan secara automatik;
lebih berskala Baik , bilangan dan struktur nod MySQL boleh dikembangkan mengikut keperluan
Berbanding dengan replikasi MySQL dua nod, MySQL tiga nod/multi-nod mempunyai kebarangkalian yang lebih rendah untuk tidak tersedia
Kelemahan:
Sekurang-kurangnya tiga nod diperlukan, yang memerlukan lebih banyak sumber daripada dua nod;
Logiknya lebih kompleks, dan lebih sukar untuk menyelesaikan masalah dan mengesan masalah selepas kegagalan berlaku;
Konsistensi data masih dijamin oleh replikasi separa segerak asli masih terdapat risiko ketidakkonsistenan data; >
Zookeeper menggunakan algoritma yang diedarkan untuk memastikan pengelompokan Untuk ketekalan data, menggunakan zookeeper secara berkesan boleh memastikan ketersediaan tinggi proksi dan mengelakkan partition rangkaian dengan lebih baik.
mempunyai skalabiliti yang baik dan boleh dikembangkan kepada Besar kelompok skala;
Kelemahan: Ketekalan data masih bergantung pada replikasi separa segerak mysql asli; Dengan pengenalan zk, logik keseluruhan sistem menjadi lebih kompleks;
2.4.1 storan kongsi SAN
Dua nod sudah mencukupi, penggunaan mudah, logik pensuisan yang mudah;
Kelemahan:
Perlu mempertimbangkan ketersediaan storan kongsi yang tinggi;
2.4.2 replikasi cakera DRBD
Apabila terdapat masalah dengan hos tempatan, salinan data yang sama masih disimpan pada hos jauh dan boleh terus digunakan, memastikan keselamatan data.
Hanya dua nod diperlukan, penggunaan mudah dan logik pensuisan yang mudah;
Kelemahan:
Mempunyai kesan yang lebih besar pada prestasi io;
Pustaka hamba tidak menyediakan operasi baca; Protokol teragih Ia boleh menyelesaikan masalah ketekalan data dengan baik. Penyelesaian yang lebih biasa adalah seperti berikut:Kluster MySQL ialah penyelesaian penggunaan kluster rasmi Ia menggunakan enjin storan NDB untuk menyandarkan data berlebihan dalam masa nyata untuk mencapai ketersediaan dan data yang tinggi ketekalan pangkalan data.
Kelebihan:
Semua menggunakan komponen rasmi dan tidak bergantung pada perisian pihak ketiga
Boleh mencapai konsistensi data yang kukuh; Kelemahan :
Ia jarang digunakan di China
Konfigurasinya lebih kompleks dan memerlukan penggunaan enjin storan NDB, yang agak berbeza daripada enjin MySQL biasa Sekurang-kurangnya tiga nod;
Kelebihan:
Penulisan berbilang induk, replikasi tanpa lengah, memastikan ketekalan data yang kukuh
Terdapat a komuniti matang , digunakan oleh syarikat Internet secara besar-besaran; Failover automatik, penambahan automatik dan penyingkiran nod
Kelemahan:
Memerlukan tampalan wsrep untuk nod MySQL asli
Sahaja enjin storan innodb yang disokong Sekurang-kurangnya tiga nod; . Algoritma ini dianggap paling cekap seumpamanya. Gabungan Paxos dan MySQL boleh mencapai konsistensi yang kukuh dalam data MySQL yang diedarkan. Seni bina biasa adalah seperti berikut:
Penulisan berbilang induk, replikasi tanpa kelewatan, memastikan ketekalan data yang kukuh
Mempunyai asas teori yang matang; Failover automatik, penambahan automatik dan penyingkiran nod;
Kelemahan:
Hanya menyokong enjin storan innodb
Sekurang-kurangnya tiga nod; 🎜>
Memandangkan keperluan orang ramai untuk konsistensi data terus meningkat, semakin banyak kaedah sedang dicuba untuk menyelesaikan masalah ketekalan data teragih, seperti pengoptimuman MySQL itu sendiri, pengoptimuman seni bina kluster MySQL, Paxos, Raft, Pengenalan algoritma 2PC dan sebagainya.
Kaedah menggunakan algoritma teragih untuk menyelesaikan masalah ketekalan data pangkalan data MySQL semakin diterima oleh orang ramai Satu siri produk matang seperti PhxSQL, MariaDB Galera Cluster, Percona XtraDB Cluster, dll. menjadi semakin popular semakin digunakan secara besar-besaran.
Dengan GA rasmi MySQL Group Replication, menggunakan protokol yang diedarkan untuk menyelesaikan masalah konsistensi data telah menjadi hala tuju arus perdana. Dijangkakan bahawa lebih banyak penyelesaian cemerlang akan dicadangkan, dan masalah ketersediaan tinggi MySQL dapat diselesaikan dengan lebih baik.
Atas ialah kandungan terperinci Susun dan ringkaskan lima penyelesaian ketersediaan tinggi MySQL biasa. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!