Mari kita bincangkan tentang cara GitHub mencapai ketersediaan tinggi MySQL

Bagaimanakah GitHub mencapai ketersediaan tinggi untuk MySQL? Artikel berikut akan dikongsikan dengan anda, semoga bermanfaat untuk semua.

Github menggunakan pangkalan data MySQL sebagai stor data untuk semua transaksi bukangit. Ketersediaan pangkalan data adalah penting untuk berfungsi dengan betul Github. Kedua-dua tapak web Github itu sendiri, API Github, perkhidmatan pengesahan, dll. semuanya perlu mengakses pangkalan data. Github menjalankan berbilang kluster pangkalan data untuk menyokong tugas perkhidmatan yang berbeza. Seni bina pangkalan data menggunakan struktur induk-hamba tradisional Satu nod (pangkalan data induk) dalam kluster menyokong akses tulis, dan nod yang tinggal (pangkalan data hamba) menyegerakkan perubahan kepada pangkalan data induk dan perkhidmatan baca sokongan.

Ketersediaan perpustakaan utama adalah penting. Setelah pangkalan data utama turun, kluster tidak akan dapat menyokong perkhidmatan penulisan data: sebarang data yang perlu disimpan tidak boleh ditulis ke pangkalan data untuk penyimpanan. Akibatnya, sebarang perubahan pada Github, seperti penyerahan kod, soalan, penciptaan pengguna, semakan kod, penciptaan gudang, dll., tidak dapat diselesaikan.

Untuk memastikan operasi normal perniagaan, kami sememangnya perlu mempunyai nod pangkalan data yang tersedia dalam kelompok yang menyokong penulisan. Pada masa yang sama, kita juga mesti dapat menemui nod pangkalan data perkhidmatan boleh tulis yang tersedia dengan cepat.

Maksudnya, dalam keadaan luar biasa, jika pangkalan data utama tidak berfungsi, kami mesti memastikan bahawa pangkalan data utama baharu boleh pergi ke dalam talian serta-merta ke perkhidmatan sokongan, dan memastikan nod lain dalam kluster dapat mengenal pasti dengan cepat pangkalan data utama baharu. Jumlah masa untuk pengesanan kesalahan, penghijrahan induk dan nod data lain dalam kelompok untuk mengenal pasti induk baharu membentuk jumlah masa gangguan perkhidmatan.

Artikel ini menerangkan ketersediaan tinggi MySQL GitHub dan penyelesaian penemuan perkhidmatan induk, yang membolehkan kami menjalankan operasi dengan pasti merentas pusat data, bertolak ansur dengan pengasingan pusat data dan memendekkan masa yang diperlukan untuk Masa Henti sekiranya berlaku kegagalan.

Pelaksanaan ketersediaan tinggi#

Penyelesaian yang diterangkan dalam artikel ini ialah versi diperbaik bagi penyelesaian ketersediaan tinggi Github sebelumnya. Seperti yang dinyatakan sebelum ini, strategi ketersediaan tinggi MySQL mesti menyesuaikan diri dengan perubahan perniagaan. Kami menjangkakan MySQL dan perkhidmatan lain di GitHub mempunyai penyelesaian yang sangat tersedia yang boleh mengatasi perubahan.

Apabila mereka bentuk penyelesaian sistem ketersediaan dan penemuan perkhidmatan yang tinggi, bermula daripada soalan berikut boleh membantu kami mencari penyelesaian yang sesuai dengan cepat:

• Gangguan perkhidmatan maksimum yang dibenarkan Apakah masanya?
• Sejauh manakah tepat pengesanan gangguan perkhidmatan? Bolehkah pengesanan gangguan perkhidmatan dibenarkan untuk mengesan positif palsu (yang membawa kepada kegagalan pramatang)?
• Sejauh manakah failover itu boleh dipercayai? Apakah keadaan yang boleh menyebabkan failover gagal?
• Bolehkah penyelesaian ini dilaksanakan merentas pusat data, dan bagaimanakah ia dilaksanakan? Apakah yang akan berlaku di bawah keadaan rangkaian yang berbeza, kependaman tinggi atau kependaman rendah?
• Bolehkah penyelesaian ini menahan keseluruhan kegagalan pusat data (DC) atau pengasingan rangkaian?
• Adakah terdapat sebarang mekanisme untuk menghalang situasi otak berpecah gugusan HA (dalam sistem keseluruhan, dua nod bersambung berpecah kepada dua nod bebas dan kedua-dua nod bersaing untuk mendapatkan sumber dikongsi untuk menulis data)?
• Bolehkah kehilangan data diterima? Apakah tahap kerugian yang boleh diterima?

Untuk menjelaskan isu di atas, mari kita lihat dahulu penyelesaian ketersediaan tinggi kami yang terdahulu dan sebab kami ingin memperbaikinya.

Tinggalkan mekanisme penemuan berdasarkan VIP dan DNS#

Dalam penyelesaian sebelumnya, penyelesaian teknikal berikut telah digunakan:

• Gunakan orkestra sebagai penyelesaian migrasi pengesanan kerosakan.
• Gunakan kaedah VIP dan DNS sebagai penyelesaian penemuan nod induk.

Pelanggan mencari nod induk dengan menghuraikan nama nod, seperti mysql-writer-1.github.net, ke dalam alamat IP mayanya (VIP).

Oleh itu, dalam keadaan biasa, pelanggan boleh menyambung ke nod induk IP yang sepadan dengan menghuraikan nama nod.

Pertimbangkan topologi tiga pusat data:

Setelah pangkalan data utama tidak normal, salah satu pelayan replika data mesti dikemas kini kepada pelayan pangkalan data utama .

orchestrator akan mengesan anomali, memilih pangkalan data induk baharu, dan kemudian menetapkan semula nama pangkalan data dan IP maya (VIP). Pelanggan itu sendiri tidak mengetahui perubahan pada perpustakaan utama Maklumat yang dimiliki klien hanyalah nama pustaka utama, jadi nama ini mesti boleh diselesaikan ke pelayan perpustakaan utama yang baharu. Pertimbangkan perkara berikut:

VIP perlu dirundingkan: IP maya dipegang oleh pangkalan data itu sendiri. Pelayan mesti menghantar permintaan ARP untuk menduduki atau melepaskan VIP. Sebelum pangkalan data baharu boleh memperuntukkan VIP baharu, pelayan lama mesti terlebih dahulu melepaskan VIP yang dipegangnya. Proses ini akan menyebabkan beberapa masalah luar biasa:

• Jujukan failover ialah meminta mesin yang gagal untuk melepaskan VIP dahulu, dan kemudian menghubungi mesin pangkalan data utama baharu untuk memperuntukkan VIP. Tetapi bagaimana jika mesin yang gagal itu sendiri tidak boleh diakses, atau enggan melepaskan VIP? Memandangkan senario kegagalan mesin, mesin yang gagal tidak akan bertindak balas serta-merta atau tidak sama sekali kepada permintaan untuk melepaskan VIP Keseluruhan proses mempunyai dua masalah berikut:
  • Situasi otak berpecah: Jika dua hos memegang. yang sama Dalam kes VIP, pelanggan yang berbeza akan menyambung ke hos yang berbeza berdasarkan pautan rangkaian terpendek.
  • Seluruh proses penugasan semula VIP bergantung pada penyelarasan dua pelayan bebas dan proses persediaan tidak boleh dipercayai.
• Walaupun mesin yang gagal mengeluarkan VIP secara normal, keseluruhan proses ini sangat memakan masa kerana proses penukaran juga memerlukan penyambungan kepada mesin yang gagal.
• Walaupun VIP ditugaskan semula, sambungan sedia ada pelanggan tidak akan diputuskan secara automatik daripada mesin lama yang gagal, menyebabkan situasi otak berpecah dalam keseluruhan sistem.

Apabila kami sebenarnya menyediakan VIP, VIP juga terikat dengan lokasi fizikal sebenar. Ini bergantung terutamanya pada tempat suis atau penghala berada. Oleh itu, kami hanya boleh menetapkan semula VIP pada pelayan tempatan yang sama. Khususnya, terdapat kes di mana kami tidak dapat menetapkan VIP kepada pelayan di pusat data lain dan mesti membuat perubahan DNS.

• Perubahan DNS mengambil masa lebih lama untuk disebarkan. Pelanggan menyimpan nama DNS terlebih dahulu dengan masa yang dikonfigurasikan. Failover merentas platform bermakna lebih banyak gangguan: pelanggan perlu meluangkan lebih banyak masa untuk mengenali pelayan utama baharu.

Keterbatasan ini sahaja sudah cukup untuk mendorong kami mencari penyelesaian baharu, tetapi berikut adalah perkara yang perlu dipertimbangkan:

• Pelayan utama menggunakan pt-heartbeat perkhidmatan untuk pergi ke suntikan diri Akses degupan jantung untuk pengukuran kependaman dan kawalan pendikit . Perkhidmatan mesti dimulakan pada pelayan induk baharu. Jika boleh, perkhidmatan pelayan utama lama akan ditutup apabila pelayan utama diganti.

• Begitu juga, Pseudo-GTID diuruskan oleh pelayan itu sendiri. Ia perlu dimulakan pada tuan baru dan sebaik-baiknya dihentikan pada tuan lama.

• Tuan baharu akan ditetapkan boleh ditulis. Jika boleh, tuan lama akan ditetapkan kepada read_only (baca sahaja).

Langkah tambahan ini merupakan faktor dalam jumlah masa henti dan memperkenalkan gangguan dan geseran mereka sendiri.

Penyelesaian berfungsi, GitHub telah berjaya melakukan failover MySQL, tetapi kami ingin HA menambah baik dalam bidang berikut:

• Agnostik pusat data.
• Bertolak ansur dengan kegagalan pusat data.
• Alih keluar aliran kerja kerjasama yang tidak boleh dipercayai.
• Kurangkan jumlah masa henti.
• Seboleh-bolehnya, dapatkan failover tanpa rugi.

Penyelesaian ketersediaan tinggi GitHub: orkestra, Konsul, GLB

Strategi baharu boleh menambah baik, menyelesaikan atau mengoptimumkan masalah yang dinyatakan di atas. Komponen ketersediaan tinggi semasa adalah seperti berikut:

• orkestra melakukan pengesanan dan failover. Gunakan pusat data hibrid seperti yang diterangkan dalam pautan orkestra/rakit .
• Hashicorp Konsul ditemui sebagai perkhidmatan.
• GLB/HAProxy bertindak sebagai proksi antara klien dan nod penulisan. Panduan GLB ialah sumber terbuka.
• anycast sebagai penghala rangkaian.

Struktur baharu mengalih keluar VIP dan DNS. Sambil kami memperkenalkan lebih banyak komponen, kami dapat memisahkannya dan memudahkan tugasan yang berkaitan dan memudahkan untuk memanfaatkan penyelesaian yang boleh dipercayai dan stabil. Butiran di bawah.

Proses biasa

Biasanya, aplikasi bersambung ke nod tulis melalui GLB/HAProxy.

Aplikasi tidak mengetahui identiti induk. Sebelum ini, nama digunakan. Contohnya, tuan cluster1 ialah mysql-writer-1.github.net. Dalam struktur semasa, nama ini digantikan dengan anycast IP.

Dengan anycast, nama digantikan dengan IP yang sama, tetapi trafik dihalakan oleh lokasi pelanggan. Khususnya, apabila pusat data mempunyai GLB, pengimbang beban ketersediaan tinggi digunakan dalam kotak yang berbeza. Trafik ke mysql-writer-1.github.net dihalakan ke gugusan GLB di pusat data tempatan. Dengan cara ini semua pelanggan dilayan oleh proksi tempatan.

Gunakan GLB di atas HAProxy. HAProxy mempunyai kumpulan tulis : satu bagi setiap kelompok MySQL. Setiap kumpulan mempunyai perkhidmatan hujung belakang: nod induk kelompok. Semua kotak GLB/HAProxy di pusat data mempunyai kumpulan yang sama, yang bermaksud bahawa kumpulan ini sepadan dengan perkhidmatan bahagian belakang yang sama. Jadi jika aplikasi menjangkakan untuk menulis mysql-writer-1.github.net, ia tidak kisah perkhidmatan GLB yang mana untuk disambungkan. Ia akan membawa kepada cluster1 nod induk sebenar.

Untuk aplikasi untuk menyambung ke GLB dan menemui perkhidmatan, tiada penemuan semula diperlukan. GLB bertanggungjawab untuk mengarahkan semua trafik ke destinasi yang betul.

Bagaimanakah GLB mengetahui perkhidmatan yang merupakan bahagian belakang, dan bagaimanakah ia memberitahu GLB tentang perubahan?

Penemuan melalui Konsul

Konsul terkenal dengan penyelesaian penemuan perkhidmatan dan juga menyediakan perkhidmatan DNS. Walau bagaimanapun, dalam penyelesaian kami, kami menggunakannya sebagai kedai nilai kunci (KV) yang sangat tersedia.

Di kedai KV Consul, kami menulis identiti tuan kluster. Untuk setiap kluster, terdapat satu set entri KV yang menunjukkan peranti induk kluster fqdn, port, ipv4, ipv6.

Setiap nod GLB/HAProxy menjalankan consul-template: perkhidmatan yang mendengar perubahan dalam data Konsul (dalam kes kami: perubahan dalam data induk kluster). consul-template Jana fail konfigurasi yang sah dan boleh memuatkan semula HAProxy apabila konfigurasi berubah.

Oleh itu, setiap mesin GLB/HAProxy akan memerhatikan perubahan identiti induk oleh Konsul, kemudian ia akan mengkonfigurasi semula dirinya, menetapkan induk baharu sebagai entiti tunggal dalam kolam hujung belakang kluster dan memuat semula untuk mencerminkan perubahan ini.

Di GitHub, kami mempunyai persediaan Konsul dalam setiap pusat data dan setiap persediaan sangat tersedia. Walau bagaimanapun, tetapan ini adalah bebas antara satu sama lain. Mereka tidak menyalin antara satu sama lain dan tidak berkongsi sebarang data.

Bagaimanakah Konsul mengetahui tentang perubahan, dan bagaimana maklumat diedarkan ke seluruh DC?

orchestrator/rakit

Kami menjalankan persediaan orchestrator/raft: orchestrator nod berkomunikasi antara satu sama lain melalui mekanisme rakit. Setiap pusat data mempunyai satu atau dua orchestrator nod.

orchestrator bertanggungjawab untuk pengesanan kesalahan dan failover MySQL, serta menyampaikan perubahan daripada master kepada Consul. Failover dikendalikan oleh satu orchestrator/raft nod ketua, tetapi mesej bahawa kluster kini mempunyai induk baharu disebarkan kepada semua raft nod melalui mekanisme orchestrator.

Apabila orchestrator nod menerima mesej yang master telah berubah, mereka masing-masing berkomunikasi dengan persediaan Consul setempat: mereka masing-masing memanggil KV write. DC dengan berbilang orchestrator proksi akan menulis berbilang masa (sama) kepada Konsul.

Gabungkan proses

Sekiranya berlaku ranap induk:

• orchestrator Kegagalan pengesanan nod.
• orchestrator/raft Nod pemimpin mula pulih, dan pelayan data dikemas kini sebagai induk.
• orchestrator/raft Umumkan semua raft nod subkluster telah bertukar induk.
• Setiap ahli orchestrator/raft menerima pemberitahuan perubahan nod pemimpin. Setiap ahli mereka mengemas kini tuan baharu ke kedai KV Consul tempatan.
• Setiap GLB/HAProxy dijalankan consul-template dan templat melihat perubahan dalam Consul gedung KV dan mengkonfigurasi semula serta memuat semula HAProxy.
• Trafik pelanggan diubah hala ke induk baharu.

Setiap komponen mempunyai tanggungjawab yang jelas, dan keseluruhan reka bentuk dipisahkan dan dipermudahkan. orchestrator Tidak tahu tentang pengimbang beban. Consul Tidak perlu tahu sumber mesej. Ejen hanya mementingkan Consul. Pelanggan hanya mengambil berat tentang proksi.

Selain itu:

• Tiada perubahan DNS untuk disebarkan
• Tiada TTL.
• Strim tidak bekerjasama dengan tuan yang gagal, ia sebahagian besarnya diabaikan.

Butiran Tambahan

Untuk melindungi lalu lintas anda, kami mempunyai perkara berikut:

• HAProxy dikonfigurasikan dengan hard-stop-after yang sangat pendek. Apabila ia memuatkan semula pelayan bahagian belakang baharu dalam kumpulan penulis, ia secara automatik menamatkan sebarang sambungan sedia ada ke pelayan induk lama.
  • Dengan hard-stop-after kami tidak memerlukan kerjasama pelanggan, yang mengurangkan situasi otak berpecah. Perlu diingat bahawa ini tidak ditutup dan beberapa masa berlalu sebelum kami menamatkan sambungan lama. Tetapi selepas satu ketika, kami berasa selesa dan tidak mengharapkan sebarang kejutan buruk.
• Kami tidak mewajibkan Konsul untuk sentiasa berhubung dengan panggilan pada setiap masa. Sebenarnya, kami hanya memerlukannya untuk tersedia di failover. Jika Konsul gagal, GLB akan terus beroperasi menggunakan nilai terakhir yang diketahui dan tidak akan mengambil tindakan drastik.
• GLB disediakan untuk mengesahkan identiti tuan yang baru dinaikkan pangkat. Sama seperti kolam MySQL peka konteks kami, semakan dilakukan pada pelayan bahagian belakang untuk mengesahkan bahawa ia sememangnya nod penulis. Jika kita kebetulan memadamkan identiti tuan di Konsul, tiada masalah entri kosong diabaikan. Jika kami tersilap menulis nama bukan induk dalam Konsul, tiada masalah GLB akan menolak untuk mengemas kininya dan terus berjalan dalam keadaan terakhir yang diketahui.

Kami akan menyelesaikan masalah tersebut dan meneruskan matlamat HA dalam bahagian berikut.

Pengesanan Kesalahan Orchestrator/RAFT

orchestrator menggunakan pendekatan holistik untuk mengesan kerosakan dan oleh itu sangat boleh dipercayai. Kami mendapati tiada positif palsu: kami tidak mengalami kegagalan pramatang dan oleh itu tidak mengalami masa henti yang tidak perlu.

orchestrator/raft Lebih lanjut menangani kes pengasingan rangkaian DC lengkap (aka DC pagar). Pengasingan rangkaian DC boleh menyebabkan kekeliruan: pelayan dalam DC itu boleh berkomunikasi antara satu sama lain. Adakah mereka diasingkan daripada rangkaian DC lain atau DC lain diasingkan daripada rangkaian?

Dalam persediaan orchestrator/raft, nod ketua raft ialah nod yang menjalankan failover. Pemimpin adalah nod yang mendapat sokongan majoriti (kuorum) kumpulan. Penggunaan nod penyelaras kami adalah sedemikian rupa sehingga tiada satu pusat data mempunyai majoriti, mana-mana pusat data n-1 akan melakukannya.

Dengan pengasingan lengkap rangkaian DC, orchestrator nod dalam DC itu akan diputuskan sambungan daripada nod rakan sebaya dalam DC lain. Oleh itu, nod orchestrator dalam DC terpencil tidak boleh menjadi ketua gugusan raft. Jika mana-mana nod sedemikian menjadi ketua, ia akan berundur. Pemimpin baharu akan ditugaskan daripada mana-mana DC lain. Pemimpin ini akan disokong oleh semua DC lain yang boleh berkomunikasi antara satu sama lain.

Oleh itu, nod orchestrator yang memberikan pesanan akan menjadi nod di luar pusat data pengasingan rangkaian. Jika terdapat induk dalam DC kendiri, orchestrator akan memulakan failover, menggantikannya dengan pelayan daripada salah satu DC yang tersedia. Kami mengurangkan pengasingan DC dengan mewakilkan keputusan kepada kuorum dalam DC tidak terpencil.

Publisiti yang lebih pantas

Jumlah masa rehat boleh dikurangkan lagi dengan menerbitkan perubahan besar dengan lebih pantas. Bagaimana untuk mencapai ini?

Apabila orchestrator memulakan failover, ia memerhati barisan pelayan yang tersedia untuk promosi. Memahami peraturan replikasi dan mematuhi petua dan had membolehkan anda membuat keputusan terpelajar tentang tindakan terbaik.

Mungkin diakui bahawa pelayan yang tersedia untuk promosi juga merupakan calon yang ideal, sebagai contoh: adalah peningkatan pilihan), dan

Pelayan dijangka dapat memiliki semua adik-beradik mereka sebagai replika.
• Dalam kes ini,
mula-mula menetapkan pelayan sebagai boleh ditulis dan kemudian dengan serta-merta mengiklankan pelayan (dalam kes kami menulis ke kedai Konsul KV), walaupun secara tidak segerak Mula membaiki pokok replikasi, operasi ini biasanya mengambil masa beberapa saat.

Ada kemungkinan pokok replikasi akan utuh sebelum pelayan GLB dimuat semula sepenuhnya, tetapi ia tidak diperlukan sepenuhnya. Pelayan sangat pandai menerima penulisan! orchestrator

Replikasi separa segerak

Dalam Replikasi separa segerak

MySQL, tuan tidak mengakui transaksi dilakukan sehingga perubahan diketahui telah dihantar kepada Satu atau lebih salinan. Ia menyediakan cara untuk mencapai failover tanpa rugi: sebarang perubahan yang digunakan pada pelayan utama sama ada digunakan pada pelayan utama atau menunggu untuk digunakan pada salah satu replika.

Konsistensi datang dengan kos: risiko ketersediaan. Jika tiada replika yang mengakui penerimaan perubahan, induk menghalang dan berhenti menulis. Nasib baik, terdapat konfigurasi tamat masa selepas itu induk boleh kembali kepada mod replikasi tak segerak, menjadikan penulisan tersedia semula.

Kami telah menetapkan tamat masa kepada nilai yang agak rendah: 500ms. Ia memadai untuk menghantar perubahan daripada replika DC induk kepada replika DC tempatan dan juga kepada DC jauh. Dengan tamat masa ini, kita boleh melihat gelagat separa segerak yang sempurna (tiada sandaran kepada replikasi tak segerak) dan boleh menggunakan tempoh penyekatan yang sangat singkat sekiranya berlaku kegagalan pengakuan.

Kami mendayakan separa penyegerakan pada replika DC tempatan dan sekiranya tuannya mati, kami menjangkakan (walaupun tidak menguatkuasakan secara ketat) failover tanpa kerugian. Failover tanpa kerugian bagi kerosakan DC yang lengkap adalah mahal dan kami tidak menjangkakannya.

Semasa bereksperimen dengan tamat masa separa segerak, kami turut melihat tingkah laku yang memihak kepada kami: dalam kes kegagalan utama, kami dapat mempengaruhi identiti calon ideal . Dengan mendayakan separa segerak pada pelayan yang ditetapkan dan menandakannya sebagai pelayan calon, kami dapat mengurangkan masa henti keseluruhan dengan mempengaruhi hasil kegagalan. Dalam percubaan kami, kami mendapati bahawa kami sering mendapat calon ideal untuk mengiklan dengan cepat.

Menyuntik degupan jantung

Daripada menguruskan permulaan/penutupan perkhidmatan pt-heart pada hos yang dinaik taraf/diturun taraf, kami memilih untuk menjalankannya di mana-mana sahaja pada bila-bila masa . Ini memerlukan beberapa tampalan untuk membuat pt-heart menyesuaikan diri dengan situasi di mana pelayan bertukar ke sana ke mari read_only (status baca sahaja) atau ranap sepenuhnya.

Dalam persediaan semasa kami, perkhidmatan pt-heart dijalankan pada induk dan replika. Pada hos, mereka menjana acara degupan jantung. Pada replika, mereka mengenal pasti pelayan sebagai read_only (baca sahaja) dan menyemak semula status mereka secara berkala. Sebaik sahaja pelayan dinaikkan untuk menguasai, pt-heart pada pelayan itu mengenal pasti pelayan sebagai boleh ditulis dan mula menyuntik peristiwa degupan jantung.

delegasi pemilikan orkestra

Kami selanjutnya orkestra:

• menyuntik Pseudo-GTID,
• akan mempromosikan tetapan induk untuk boleh ditulis, kosongkan status replikasinya dan,
• jika boleh, tetapkan induk lama kepada read_only.

Di samping semua pakar baharu, ini mengurangkan geseran. Guru yang baru dinaikkan pangkat pastinya masih hidup dan boleh diterima, jika tidak, kami tidak akan mempromosikannya. Oleh itu, masuk akal untuk membiarkan orchestrator secara langsung bercakap tentang menukar msater yang harus digunakan untuk rangsangan.

delegasi pemilikan orkestra

Kami selanjutnya orkestra:

• Suntikan Pseudo-GTID,
• akan mempromosikan tetapan induk Boleh ditulis, kosongkan status replikasinya dan,
• tetapkan tuan lama kepada read_only jika boleh.

Di samping semua pakar baharu, ini mengurangkan geseran. Guru yang baru dinaikkan pangkat pastinya masih hidup dan boleh diterima, jika tidak, kami tidak akan mempromosikannya. Oleh itu, masuk akal untuk orchestrator menerapkan perubahan secara terus kepada msater yang dinaikkan pangkat.

Batasan dan Kelemahan

Lapisan proksi menjadikan identiti pelayan induk tidak diketahui oleh aplikasi, tetapi ia juga menutup identiti pelayan induk daripada aplikasi. Apa yang dilihat terutamanya adalah sambungan yang datang dari lapisan proksi, dan kami kehilangan maklumat tentang asal sambungan sebenar.

Dengan pembangunan sistem teragih, kami masih berhadapan dengan senario yang tidak dapat dikendalikan.

Perlu diambil perhatian bahawa dalam senario pengasingan pusat data, dengan mengandaikan pelayan utama terletak di DC terpencil, aplikasi dalam DC itu masih boleh menulis ke pelayan utama. Ini boleh menyebabkan keadaan tidak konsisten sebaik sahaja rangkaian dipulihkan. Kami sedang berusaha untuk mengurangkan otak berpecah ini dengan melaksanakan STONITH DC yang boleh dipercayai yang sangat terpencil dari dalam. Seperti sebelum ini, ia akan mengambil sedikit masa sebelum sekolah utama dimusnahkan, dan mungkin terdapat satu tempoh singkat untuk memecahkan otak. Kos operasi untuk mengelakkan pecah otak adalah sangat tinggi.

Terdapat lebih banyak kes: menghentikan perkhidmatan konsul pada pengasingan separa DC; Kami tahu adalah mustahil untuk memasukkan semua kelemahan dalam sistem yang diedarkan seperti ini, jadi kami memberi tumpuan kepada kes yang paling penting.

Kesimpulan

Penyelaras/GLB/Konsul kami memberikan kami:

• Pengesanan kegagalan yang boleh dipercayai,
• failover bebas pusat data,
• Biasanya failover tanpa kerugian,
• Sokongan pengasingan rangkaian pusat data,
• Mengurangkan otak berpecah (lebih banyak kerja dilakukan),
• tidak bergantung pada kerjasama,
• dalam kebanyakan kes, jumlah masa gangguan adalah antara 10 and 13 seconds.
  • Dalam kes yang jarang berlaku, kita boleh melihat sehingga 20 seconds jumlah masa henti, dan dalam kes yang melampau sehingga 25 seconds masa henti.

Kesimpulan

Paradigma penemuan proses/proksi/perkhidmatan menggunakan komponen yang terkenal dan dipercayai dalam seni bina yang dipisahkan, Ini menjadikannya lebih mudah untuk menggunakan, mengendalikan dan memerhati, dan setiap komponen boleh ditingkatkan atau diturunkan secara bebas. Kami sentiasa boleh menguji tetapan dan mencari penambahbaikan.

Alamat asal: https://github.blog/2018-06-20-mysql-high-availability-at-github/

Alamat terjemahan: https://learnku .com/mysql/t/36820

[Cadangan berkaitan: tutorial video mysql]

Atas ialah kandungan terperinci Mari kita bincangkan tentang cara GitHub mencapai ketersediaan tinggi MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!