Di Citymobil kami nganggo database MySQL salaku panyimpen data pengkuh utama kami. Kami ngagaduhan sababaraha klaster database pikeun sagala rupa jasa sareng tujuan.

Kasadiaan konstan master mangrupakeun indikator kritis kinerja sakabéh sistem jeung bagian individu. Pamulihan kluster otomatis upami aya kagagalan master ngirangan waktos réspon kajadian sareng downtime sistem. Dina tulisan ieu, kuring bakal ningali desain kasadiaan tinggi (HA) pikeun klaster MySQL dumasar kana MySQL Orchestrator jeung alamat IP virtual (VIP).

solusi HA dumasar kana VIP

Kahiji, kuring sakeudeung bakal nyaritakeun naon sistem panyimpen data urang.

Kami nganggo skéma réplikasi klasik sareng hiji master anu tiasa diaksés sareng sababaraha réplika anu dibaca wungkul. Kluster tiasa ngandung master perantara - titik anu mangrupikeun réplika sareng master pikeun anu sanés. Klién ngaksés réplika ngalangkungan HAProxy, anu ngamungkinkeun distribusi beban sareng skala gampang. Pamakéan HAProxy téh alatan alesan sajarah, sarta kami ayeuna dina prosés migrasi ka ProxySQL.

Réplikasi dipigawé dina modeu semi-sinkron dumasar kana GTID. Ieu ngandung harti yén sahenteuna hiji réplika kedah log transaksi sateuacan dianggap suksés. Modeu réplikasi ieu nyayogikeun kasaimbangan anu optimal antara kinerja sareng kaamanan data upami aya gagalna master node. Dasarna sagala parobahan ditransfer ti master kana réplika ngagunakeun Row Based Replication (RBR), tapi sababaraha titik mungkin gaduh mixed binlog format.

Orchestrator périodik ngamutahirkeun kaayaan topologi klaster, nganalisa inpormasi anu ditampi, sareng upami aya masalah, éta tiasa ngaluncurkeun prosedur pamulihan otomatis. Pamekar tanggung jawab pikeun prosedur sorangan, sabab tiasa dilaksanakeun ku sababaraha cara: dumasar kana VIP, DNS, nganggo jasa penemuan jasa atanapi mékanisme anu ditulis nyalira.

Hiji cara basajan pikeun mulangkeun master lamun gagal nyaéta ngagunakeun alamat VIP ngambang.

Naon anu anjeun kedah terang ngeunaan solusi ieu sateuacan maju:

• VIP mangrupikeun alamat IP anu henteu aya hubunganana sareng antarmuka jaringan fisik khusus. Upami node gagal atanapi salami pangropéa anu dijadwalkeun, urang tiasa ngalihkeun VIP ka sumber anu sanés kalayan downtime minimal.
• Ngabébaskeun sareng ngaluarkeun alamat IP virtual mangrupikeun operasi anu murah sareng gancang.
• Pikeun digawe sareng VIP, anjeun peryogi aksés ka server via SSH, atanapi nganggo utilitas khusus, contona, keepalived.

Hayu urang tingali masalah anu mungkin sareng wizard urang sareng bayangkeun kumaha mékanisme pamulihan otomatis kedah jalan.

Konektipitas jaringan ka master parantos ngaleungit, atanapi aya masalah anu timbul dina tingkat hardware, sareng server henteu sayogi

1. Orkestra ngamutahirkeun topologi klaster, unggal réplika ngalaporkeun yén master henteu sayogi. Orchestrator ngamimitian prosés milih réplika anu cocog pikeun peran master énggal sareng ngamimitian pamulihan.
2. Urang nyobian nyabut VIP ti master heubeul - tanpa hasil.
3. Réplika ngalih kana peran master. Topologi keur diwangun deui.
4. Nambahkeun panganteur jaringan anyar kalawan VIP. Kusabab éta teu mungkin pikeun ngahapus VIP, urang mimitian périodik ngirim pamundut di tukang ARP gratuitous. Jenis pamundut / réspon ieu ngamungkinkeun anjeun pikeun ngapdet tabel pemetaan alamat IP sareng MAC dina saklar anu disambungkeun, ku kituna ngawartosan yén VIP kami parantos ngalih. Ieu ngaminimalkeun kamungkinan split brain nalika mulang juragan heubeul.
5. Sadaya sambungan anyar langsung dialihkeun ka master anyar. Sambungan heubeul gagal jeung nelepon ulang ka database dijieun dina tingkat aplikasi.

Server beroperasi dina modeu normal, aya kagagalan dina tingkat DBMS

Algoritma sami sareng kasus saméméhna: ngamutahirkeun topologi sareng ngamimitian prosés pamulihan. Kusabab server geus sadia, urang hasil ngaleupaskeun VIP on master heubeul, mindahkeun ka nu anyar, sarta ngirimkeun sababaraha requests ARP. Kamungkinan balik master heubeul teu kudu mangaruhan klaster rebuilt jeung operasi aplikasi.

Masalah séjén

Gagalna réplika atanapi master panengah teu ngarah kana lampah otomatis tur merlukeun campur manual.

Antarbeungeut jaringan virtual sok ditambah samentawis, nyaéta, saatos reboot server, VIP henteu otomatis ditugaskeun. Unggal conto database dimimitian dina mode baca-hijina sacara standar, orkestra sacara otomatis ngalihkeun master anyar pikeun nyerat sareng nyobian masang. read only dina master heubeul. lampah ieu aimed dina ngurangan likelihood split brain.

Masalah tiasa timbul nalika prosés pamulihan, anu ogé kedah dibéjaan ngaliwatan UI orkestra salian alat ngawaskeun standar. Kami parantos ngalegaan REST API ku nambihan fitur ieu (PR ayeuna nuju ditinjau).

Diagram umum tina solusi HA dibere handap.

Milih master anyar

Orkestra cukup pinter sareng nyobian milih réplika anu paling cocog salaku master anyar dumasar kana kriteria ieu:

• replica lags tukangeun master;
• Vérsi MySQL master sareng replika;
• tipe réplikasi (RBR, SBR atawa dicampur);
• lokasi di puseur data anu sarua atawa béda;
• kasadiaan errant GTID - transaksi anu dieksekusi dina réplika sareng henteu aya dina master;
• aturan Pilihan custom ogé dicokot kana rekening.

Henteu unggal cue mangrupikeun calon idéal pikeun master. Contona, réplika tiasa dianggo pikeun nyadangkeun data, atanapi pangladén gaduh konfigurasi hardware anu langkung lemah. Orkestra ngadukung aturan manual jeung nu Anjeun bisa ngaluyukeun preferensi pilihan calon anjeun ti paling pikaresep teu dipaliré.

Tanggapan sareng waktos pamulihan

Upami aya kajadian, penting pikeun ngaminimalkeun waktos downtime sistem, janten hayu urang pertimbangkeun parameter MySQL anu mangaruhan nyiptakeun sareng ngapdet topologi klaster ku orkestra:

• slave_net_timeout — Jumlah detik nalika réplika ngadagoan data énggal atanapi sinyal denyut jantung sumping ti master sateuacan sambunganna diakui leungit sareng dihubungkeun deui. Nu handap nilai, nu leuwih gancang replika bisa nangtukeun yén komunikasi jeung master rusak. Urang nyetel nilai ieu 5 detik.
• MASTER_CONNECT_RETRY — Jumlah detik antara usaha sambungan deui. Upami aya masalah jaringan, nilai anu rendah pikeun parameter ieu bakal ngajantenkeun sambungan deui gancang sareng nyegah prosés pamulihan klaster dimimitian. Nilai anu disarankeun nyaéta 1 detik.
• MASTER_RETRY_COUNT - Jumlah maksimum usaha reconnection.
• MASTER_HEARTBEAT_PERIOD - interval dina detik sanggeus nu master ngirimkeun sinyal keteg jajantung. Defaults kana satengah nilai slave_net_timeout.

Parameter orkestra:

• DelayMasterPromotionIfSQLThreadNotUpToDate - lamun sarua true, mangka peran master moal dilarapkeun dina replica calon dugi thread SQL replica urang geus réngsé sakabéh transaksi unapplied ti Relay Log. Kami nganggo pilihan ieu pikeun ngahindarkeun kaleungitan transaksi nalika sadaya réplika calon mundur.
• InstancePollSeconds - Frékuénsi ngawangun sareng ngamutahirkeun topologi.
• RecoveryPollSeconds - frékuénsi analisis topologi. Upami aya masalah dideteksi, pamulihan topologi dimimitian. Ieu ajeg, sarua jeung 1 detik.

Unggal titik kluster ditaros ku orkestra sakali unggal InstancePollSeconds detik Nalika masalah dideteksi, kaayaan klaster kapaksa diropéa, lajeng kaputusan final dijieun pikeun nedunan recovery. Ku ékspérimén sareng databés sareng parameter orkestra anu béda, kami tiasa ngirangan réspon sareng waktos pamulihan dugi ka 30 detik.

bangku tés

Urang mimitian nguji skéma HA kalawan ngembangkeun hiji lokal bangku tés sareng palaksanaan salajengna dina uji sareng lingkungan produksi. Stand lokal pinuh otomatis dumasar kana Docker tur ngidinan Anjeun pikeun ékspérimén kalawan konfigurasi tina orchestrator jeung jaringan, skala klaster tina 2-3 server ka sababaraha belasan, sarta ngalaksanakeun latihan di lingkungan aman.

Salila latihan, urang milih salah sahiji metodeu emulation masalah: instan némbak master ngagunakeun kill -9, liren ngeureunkeun prosés sareng ngeureunkeun server (docker-compose stop), simulate masalah jaringan ngagunakeun iptables -j REJECT atawa iptables -j DROP. Kami ngarepkeun hasil di handap ieu:

• orkestra bakal ngadeteksi masalah sareng master sareng ngapdet topologi dina henteu langkung ti 10 detik;
• prosedur recovery bakal otomatis dimimitian: konfigurasi jaringan bakal robah, peran master bakal lulus replica nu, topology bakal diwangun deui;
• master anyar bakal bisa ditulis, réplika hirup moal leungit salila prosés ngawangun deui;
• data bakal mimiti ditulis ka master anyar jeung replicated;
• Total waktu recovery moal leuwih ti 30 detik.

Sakumaha anjeun terang, sistem tiasa kalakuanana béda dina lingkungan tés sareng produksi kusabab konfigurasi hardware sareng jaringan anu béda, bédana beban sintétik sareng nyata, jsb. Ku alatan éta, urang périodik ngalaksanakeun latihan dina kaayaan nyata, mariksa kumaha sistem behaves nalika konektipitas jaringan leungit atawa bagian individu na didegradasi. Dina mangsa nu bakal datang, urang rék ngawangun infrastruktur lengkep idéntik pikeun duanana lingkungan jeung ngajadikeun otomatis nguji na.

papanggihan

Kaséhatan titik sistem panyimpen utama mangrupikeun salah sahiji tugas utama SRE sareng tim operasi. Palaksanaan orchestrator sareng solusi HA dumasar kana VIP ngamungkinkeun urang pikeun ngahontal hasil ieu:

• deteksi dipercaya tina masalah sareng topologi klaster database;
• réspon otomatis sareng gancang kana kajadian anu aya hubunganana sareng master, ngirangan downtime sistem.

Nanging, solusina ngagaduhan watesan sareng kalemahan:

• skala skéma HA ka sababaraha puseur data bakal merlukeun hiji jaringan L2 tunggal antara aranjeunna;
• Sateuacan napelkeun VIP dina master anyar, urang kedah ngaleupaskeun dina anu lami. Prosésna sequential, nu ngaronjatkeun waktu recovery;
• ngaleupaskeun VIP merlukeun aksés SSH ka server, atawa metoda sejenna nelepon prosedur jauh. Kusabab server atanapi pangkalan data ngalaman masalah anu nyababkeun prosés pamulihan, kami henteu tiasa mastikeun yén panyabutan VIP bakal suksés. Sareng ieu tiasa ngakibatkeun penampilan dua server sareng alamat IP maya anu sami sareng masalah split brain.

Pikeun nyingkahan split brain, anjeun tiasa nganggo metodeu STONITH ("Tembak Titik Séjénna Dina Sirah"), anu lengkep ngasingkeun atanapi nganonaktipkeun titik masalah. Aya cara séjén pikeun nerapkeun klaster kasadiaan tinggi: kombinasi VIP tur DNS, jasa kapanggihna sarta jasa proxy, réplikasi sinkron jeung métode séjénna anu boga kalemahan jeung kaunggulan sorangan.

Kuring ngobrol ngeunaan pendekatan urang pikeun nyieun klaster failover MySQL. Gampang pikeun nerapkeun sareng nyayogikeun tingkat reliabilitas anu tiasa ditampi dina kaayaan ayeuna. Nalika sakabéh sistem umumna sareng infrastruktur khususna berkembang, pendekatan ieu pasti bakal mekar.

sumber: www.habr.com