Ing Citymobil kita nggunakake database MySQL minangka panyimpenan data persisten utama kita. Kita duwe sawetara klompok database kanggo macem-macem layanan lan tujuan.

Kasedhiya pancet master minangka indikator kritis kinerja kabeh sistem lan bagean individu. Pemulihan kluster otomatis nalika gagal master nyuda wektu nanggepi kedadean lan downtime sistem. Ing artikel iki, aku bakal ndeleng desain kasedhiyan dhuwur (HA) kanggo kluster MySQL adhedhasar MySQL Orchestrator lan alamat IP virtual (VIP).

solusi HA adhedhasar VIP

Kaping pisanan, aku bakal ngandhani kanthi ringkes babagan sistem panyimpenan data kita.

Kita nggunakake skema replikasi klasik kanthi siji master sing bisa diakses kanthi nulis lan sawetara replika mung diwaca. Kluster bisa ngemot master penengah - simpul sing minangka replika lan master kanggo wong liya. Klien ngakses replika liwat HAProxy, sing ngidini distribusi beban lan skala gampang. Panggunaan HAProxy amarga alasan historis, lan saiki kita lagi proses migrasi menyang ProxySQL.

Replikasi dileksanakake ing mode semi-sinkron adhedhasar GTID. Iki tegese paling ora siji replika kudu mlebu transaksi sadurunge dianggep sukses. Mode replikasi iki nyedhiyakake keseimbangan optimal antarane kinerja lan safety data yen ana kegagalan master node. Sejatine kabeh owah-owahan ditransfer saka master menyang replika nggunakake Row Based Replication (RBR), nanging sawetara kelenjar bisa uga duwe mixed binlog format.

Orkestra kanthi periodik nganyari negara topologi kluster, nganalisa informasi sing ditampa, lan yen ana masalah, bisa miwiti prosedur pemulihan otomatis. Pangembang tanggung jawab kanggo prosedur kasebut dhewe, amarga bisa ditindakake kanthi cara sing beda-beda: adhedhasar VIP, DNS, nggunakake layanan panemuan layanan utawa mekanisme sing ditulis dhewe.

Salah sawijining cara sing gampang kanggo mulihake master yen gagal yaiku nggunakake alamat VIP ngambang.

Apa sampeyan kudu ngerti babagan solusi iki sadurunge maju:

• VIP minangka alamat IP sing ora ana gandhengane karo antarmuka jaringan fisik tartamtu. Yen simpul gagal utawa sajrone pangopènan sing dijadwal, kita bisa ngalih VIP menyang sumber daya liyane kanthi downtime minimal.
• Mbebasake lan nerbitake alamat IP virtual minangka operasi sing murah lan cepet.
• Kanggo nggarap VIP, sampeyan butuh akses menyang server liwat SSH, utawa nggunakake utilitas khusus, contone, keepalived.

Ayo goleki masalah sing bisa ditindakake karo tuntunan kita lan bayangake kepiye mekanisme pemulihan otomatis.

Konektivitas jaringan menyang master wis ilang, utawa ana masalah ing tingkat hardware, lan server ora kasedhiya

1. Orkestra nganyari topologi kluster, saben replika nyatakake yen master ora kasedhiya. Orkestra miwiti proses milih replika sing cocog kanggo peran master anyar lan miwiti pemulihan.
2. Kita nyoba mbusak VIP saka master lawas - tanpa sukses.
3. Replika ngalih menyang peran master. Topologi lagi dibangun maneh.
4. Nambahake antarmuka jaringan anyar karo VIP. Wiwit iku ora bisa kanggo mbusak VIP, kita miwiti periodik ngirim panjalukan ing latar mburi ARP gratis. Panyuwunan / tanggepan jinis iki ngidini sampeyan nganyari tabel pemetaan alamat IP lan MAC ing switch sing disambungake, saéngga menehi kabar yen VIP kita wis pindhah. Iki nyilikake kemungkinan split brain nalika bali menyang master lawas.
5. Kabeh sambungan anyar langsung dialihake menyang master anyar. Sambungan lawas gagal lan telpon bola-bali menyang database digawe ing tingkat aplikasi.

Server beroperasi ing mode normal, ana kegagalan ing tingkat DBMS

Algoritma kasebut padha karo kasus sadurunge: nganyari topologi lan miwiti proses pemulihan. Wiwit server kasedhiya, kita kasil ngeculake VIP ing master lawas, nransfer menyang anyar, lan ngirim sawetara panjalukan ARP. Bisa bali saka master lawas ngirim ora mengaruhi kluster dibangun maneh lan operasi aplikasi.

Masalah liyane

Gagal replika utawa master penengah ora mimpin kanggo tumindak otomatis lan mbutuhake intervensi manual.

Antarmuka jaringan virtual tansah ditambahake kanggo sementara, yaiku, sawise urip maneh server, VIP ora ditugasake kanthi otomatis. Saben conto database diwiwiti ing mode mung diwaca kanthi standar, orkestra kanthi otomatis ngalih master anyar kanggo nulis lan nyoba nginstal. read only ing master lawas. Tumindak kasebut ditujokake kanggo nyuda kemungkinan split brain.

Masalah bisa uga muncul sajrone proses pemulihan, sing uga kudu dilaporake liwat UI orkestra saliyane alat pemantauan standar. Kita wis nggedhekake REST API kanthi nambahake fitur iki (PR saiki lagi ditinjau).

Diagram umum saka solusi HA kapacak ing ngisor iki.

Milih master anyar

Orkestra cukup pinter lan nyoba milih replika sing paling cocok minangka master anyar miturut kritéria ing ngisor iki:

• replika lags konco master;
• MySQL versi master lan replika;
• jinis replikasi (RBR, SBR utawa campuran);
• lokasi ing pusat data sing padha utawa beda;
• kasedhiya errant GTID - transaksi sing dileksanakake ing replika lan ora ana ing master;
• aturan pilihan adat uga dijupuk menyang akun.

Ora saben isyarat minangka calon sing cocog kanggo master. Contone, replika bisa digunakake kanggo nggawe serep data, utawa server duwe konfigurasi hardware sing luwih lemah. Orkestra ndhukung aturan manual karo sampeyan bisa ngatur preferensi pilihan calon saka paling disenengi kanggo digatèkaké.

Respon lan wektu pemulihan

Yen kedadeyan, penting kanggo nyilikake downtime sistem, mula ayo nimbang parameter MySQL sing mengaruhi nggawe lan nganyari topologi kluster dening orkestra:

• slave_net_timeout - jumlah detik sajrone replika ngenteni data anyar utawa sinyal deg-degan teka saka master sadurunge sambungan kasebut diakoni minangka ilang lan disambungake maneh. Sing luwih murah regane, luwih cepet replika bisa nemtokake manawa komunikasi karo master rusak. Kita nyetel nilai iki kanggo 5 detik.
• MASTER_CONNECT_RETRY - nomer detik antarane nyoba sambungan maneh. Yen ana masalah jaringan, nilai sing kurang kanggo parameter iki bakal ngidini panyambungan maneh kanthi cepet lan nyegah proses pemulihan kluster diwiwiti. Nilai sing disaranake yaiku 1 detik.
• MASTER_RETRY_COUNT - jumlah maksimum nyoba reconnection.
• MASTER_HEARTBEAT_PERIOD - interval ing sawetara detik sawise master ngirim sinyal deg-degan. Default kanggo setengah nilai slave_net_timeout.

Parameter Orkestra:

• DelayMasterPromotionIfSQLThreadNotUpToDate - yen padha true, banjur peran master ora bakal diterapake ing replika calon nganti thread SQL replika wis ngrampungake kabeh transaksi sing ora ditrapake saka Log Relay. Kita nggunakake pilihan iki supaya transaksi ilang nalika kabeh replika calon tiba konco.
• InstancePollSeconds - frekuensi mbangun lan nganyari topologi.
• RecoveryPollSeconds - frekuensi analisis topologi. Yen masalah dideteksi, pemulihan topologi bakal diwiwiti. Iki pancet, padha karo 1 detik.

Saben simpul kluster dipolling dening orkestra sapisan InstancePollSeconds detik Nalika masalah dideteksi, negara cluster dipeksa dianyari, banjur kaputusan final digawe kanggo nindakake Recovery. Kanthi nyobi karo database beda lan paramèter orkestra, kita bisa ngurangi respon lan wektu Recovery kanggo 30 detik.

bangku test

Kita miwiti nguji skema HA kanthi pangembangan lokal bangku test lan implementasine luwih ing test lan lingkungan produksi. Stand lokal kanthi otomatis adhedhasar Docker lan ngidini sampeyan eksprimen karo konfigurasi orkestra lan jaringan, skala kluster saka 2-3 server dadi sawetara rolas, lan nindakake latihan ing lingkungan sing aman.

Sajrone latihan, kita milih salah sawijining metode emulasi masalah: langsung njupuk master nggunakake kill -9, alon-alon mungkasi proses lan mungkasi server (docker-compose stop), simulasi masalah jaringan nggunakake iptables -j REJECT utawa iptables -j DROP. Kita ngarepake asil ing ngisor iki:

• orkestra bakal ndeteksi masalah karo master lan nganyari topologi ing ora luwih saka 10 detik;
• prosedur pemulihan bakal diwiwiti kanthi otomatis: konfigurasi jaringan bakal diganti, peran master bakal diterusake menyang replika, topologi bakal dibangun maneh;
• master anyar bakal bisa ditulis, replika urip ora bakal ilang sajrone proses mbangun maneh;
• data bakal miwiti ditulis kanggo master anyar lan replikasi;
• Wektu pemulihan total ora bakal luwih saka 30 detik.

Kaya sing sampeyan ngerteni, sistem kasebut bisa tumindak beda ing lingkungan tes lan produksi amarga konfigurasi hardware lan jaringan sing beda, bedane beban sintetik lan nyata, lsp. Mula, kita sacara periodik nganakake latihan ing kahanan nyata, mriksa kepiye sistem tumindak nalika konektivitas jaringan ilang utawa bagean-bageane rusak. Ing mangsa ngarep, kita pengin mbangun infrastruktur sing padha kanggo loro lingkungan lan ngotomatisasi tes kasebut.

temonan

Kesehatan simpul sistem panyimpenan utama minangka salah sawijining tugas utama SRE lan tim operasi. Implementasi solusi orkestra lan HA adhedhasar VIP ngidini kita entuk asil ing ngisor iki:

• deteksi dipercaya masalah karo topologi kluster database;
• respon otomatis lan cepet kanggo kedadean-related master, ngurangi downtime sistem.

Nanging, solusi kasebut duwe watesan lan kekurangan:

• skala skema HA kanggo sawetara pusat data mbutuhake jaringan L2 siji ing antarane;
• Sadurunge menehi VIP ing master anyar, kita kudu ngeculake sing lawas. Proses kasebut kanthi urutan, sing nambah wektu pemulihan;
• ngeculake VIP mbutuhake akses SSH menyang server, utawa cara liya kanggo nelpon prosedur remot. Wiwit server utawa database ngalami masalah sing nyebabake proses pemulihan, kita ora bisa yakin manawa pambusakan VIP bakal rampung kanthi sukses. Lan iki bisa mimpin kanggo katon loro server karo alamat IP virtual padha lan masalah split brain.

Kanggo nyingkiri split brain, sampeyan bisa nggunakake cara STONITH ("Tembak Node Liyane Ing Kepala"), sing ngisolasi utawa mateni simpul masalah. Ana cara liya kanggo ngleksanakake kasedhiyan dhuwur kluster: kombinasi VIP lan DNS, panemuan layanan lan layanan proxy, replikasi sinkron lan cara liyane sing duwe kekurangan lan kaluwihan dhewe.

Aku ngomong babagan pendekatan kita kanggo nggawe kluster failover MySQL. Gampang dileksanakake lan nyedhiyakake tingkat linuwih sing bisa ditampa ing kahanan saiki. Nalika kabeh sistem umume lan infrastruktur utamane berkembang, pendekatan iki mesthi bakal berkembang.

Source: www.habr.com