Orchestrator kanggo MySQL: kenapa sampeyan ora bisa mbangun proyek toleransi kesalahan tanpa

Sembarang proyek gedhe diwiwiti kanthi sawetara server. Kaping pisanan ana siji server DB, banjur budak ditambahake kanggo skala maca. Banjur - mandheg! Ana siji bendara, nanging bature akeh; yen salah siji saka budhak lunga, kabeh bakal apik, nanging yen master ninggalake, iku bakal ala: downtime, admin nyoba kanggo mundhakaken server. Apa sing kudu ditindakake? Cadangan master. Kolegaku Pavel wis nulis babagan iki artikel, Aku ora bakal mbaleni. Nanging, aku bakal ngandhani sampeyan kenapa sampeyan butuh Orchestrator kanggo MySQL!

Ayo dadi miwiti karo pitakonan utama: "Kepiye carane ngalih kode menyang mesin anyar nalika master ninggalake?"

• Aku seneng skema karo VIP (Virtual IP) paling, kita bakal pirembagan bab ing ngisor iki. Iku sing paling gampang lan paling ketok, sanajan ana watesan sing jelas: master sing bakal ditindakake kudu ana ing segmen L2 kanthi mesin anyar, yaiku, kita bisa lali babagan DC kapindho. Lan, ing cara amicable, yen sampeyan tindakake aturan sing L2 gedhe iku ala, amarga L2 mung saben rak, lan L3 antarane rak, lan rencana kuwi wis watesan luwih.
• Sampeyan bisa nulis jeneng DNS ing kode lan ngrampungake liwat /etc/hosts. Nyatane, ora bakal ana resolusi. Kauntungan saka skema: ora ana watesan karakteristik cara pisanan, yaiku, sampeyan bisa ngatur cross-DC. Nanging banjur ana pitakonan sing jelas: sepira cepet kita bisa ngirim owah-owahan menyang / etc / hosts liwat Puppet-Ansible?
• Sampeyan bisa ngganti cara liya sethithik: nginstal cache DNS ing kabeh server web, sing kode kasebut bakal menyang database master. Sampeyan bisa nyetel TTL 60 kanggo entri iki ing DNS. Kayane yen ditindakake kanthi bener, cara kasebut apik.
• Skema karo panemuan layanan, tegese nggunakake Konsul lan etc.
• Pilihan menarik karo ProxySQL. Sampeyan kudu nuntun kabeh lalu lintas menyang MySQL liwat ProxySQL; ProxySQL dhewe bisa nemtokake sapa sing dadi master. Miturut cara, sampeyan bisa maca babagan salah siji opsi kanggo nggunakake produk iki ing sandi artikel.

Penulis Orchestrator, sing kerja ing Github, pisanan ngetrapake skema pisanan karo VIP, banjur diowahi dadi skema karo konsul.

Tata letak infrastruktur umum:

Aku bakal langsung njlentrehake kahanan sing jelas sing kudu digatekake:

• Alamat VIP ora kudu didaftar ing konfigurasi ing server apa wae. Ayo mbayangno kahanan: master rebooted, lan nalika lagi loading, Orchestrator pindhah menyang mode failover lan nggawe salah siji saka babu master; banjur master lawas wungu, lan saiki VIP ing rong mobil. Iki ala.
• Kanggo orkestra, sampeyan kudu nulis naskah kanggo nelpon master lawas lan master anyar. Ing master lawas sampeyan kudu mbukak ifdown, lan master anyar - ifup vip. Iku bakal apik kanggo uga kalebu ing script iki yen ana failover, port ing saklar master lawas mung dipateni supaya splitbrain.
• Sawise Orchestrator wis disebut script kanggo mbusak VIP pisanan lan / utawa mateni port ing ngalih, lan banjur disebut VIP mundhakaken script ing master anyar, aja lali nggunakake printah arping kanggo pitutur marang kabeh wong sing VIP anyar saiki. kene.
• Kabeh budak kudu duwe read_only = 1, lan sanalika sampeyan promosi budak menyang master, kudu read_only = 0.
• Aja lali manawa budak sing dipilih kanggo iki bisa dadi master (Orchestrator duwe mekanisme preferensi kabeh sing kudu dianggep minangka calon master anyar ing wiwitan, sing nomer loro, lan budak sing kudu ditindakake. ora dipilih kabeh ing kahanan apa wae master). Yen batur mau dadi bendara, bebane batur mau tetep ana ing kono lan ditambahi bebane bendarane, iki kudu digatekake.

Napa sampeyan butuh Orkestra yen sampeyan ora duwe?

• Orchestrator nduweni antarmuka grafis sing ramah pangguna sing nampilake kabeh topologi (ndeleng gambar ing ngisor iki).
• Orchestrator bisa nglacak babu sing ketinggalan, lan ing ngendi replikasi umume rusak (kita duwe skrip sing dipasang ing Orchestrator kanggo ngirim SMS).
• Orkestra ngandhani babu sing duwe kesalahan GTID.

Antarmuka Orkestra:

Apa kesalahan GTID?

Ana rong syarat utama kanggo Orchestrator bisa kerja:

• Perlu yen pseudo GTID diaktifake ing kabeh mesin ing kluster MySQL; kita wis ngaktifake GTID.
• Sampeyan perlu sing ana siji jinis binlogs nang endi wae, sampeyan bisa nggunakake statement. Kita wis konfigurasi kang master lan paling babu wis Row, lan loro historis tetep ing mode Campuran. Akibaté, Orkestra mung ora pengin nyambungake budak iki menyang master anyar.

Elinga yen sing paling penting ing budak produksi yaiku konsistensi karo master! Yen sampeyan duwe ID Transaksi Global (GTID) aktif ing master lan abdi, sampeyan bisa nggunakake fungsi gtid_subset kanggo mangerteni apa panjalukan sing padha kanggo owah-owahan data wis bener wis kaleksanan ing mesin iki. Sampeyan bisa maca liyane babagan iki kene.

Mangkono, Orchestrator nuduhake sampeyan liwat kesalahan GTID yen ana transaksi ing budak sing ora ana ing master. Yagene iki kedadeyan?

• Read_only=1 ora diaktifake ing abdi, wong nyambung lan ngrampungake panjalukan kanggo ngganti data.
• Super_read_only=1 ora diaktifake ing abdi, banjur admin, sawise bingung server, mlebu lan kaleksanan panjalukan ana.
• Yen sampeyan nganggep loro poin sadurunge, ana siji trik liyane: ing MySQL, panjalukan kanggo flush binlog uga menyang binlog, supaya ing flush pisanan, kesalahan GTID bakal katon ing master lan kabeh budak. Carane supaya iki? Perona-5.7.25-28 ngenalaken binlog_skip_flush_commands = 1 setelan, kang nglarang nulis flush kanggo binlogs. Ana sing mapan ing situs web mysql.com bug.

Ayo kula ngringkes kabeh ing ndhuwur. Yen sampeyan ora pengin nggunakake Orchestrator ing mode failover, banjur lebokake ing mode observasi. Banjur sampeyan bakal tansah duwe sadurunge mata peta interaksi mesin MySQL lan informasi visual babagan apa jinis réplikasi ing saben mesin, apa babu sing lagging konco, lan sing paling Jahwéh, carane konsisten padha karo master!

Pitakonan sing jelas yaiku: "Kepiye cara kerja Orkestra?" Dheweke kudu milih master anyar saka budak saiki, banjur sambungake maneh kabeh budak menyang (iki sing dibutuhake GTID; yen sampeyan nggunakake mekanisme lawas karo binlog_name lan binlog_pos, banjur ngalih budak saka master saiki menyang anyar. mung mokal!). Sadurunge duwe Orkestra, aku kudu nindakake kabeh kanthi manual. Master lawas digantung amarga kontrol Adaptec buggy; iku duwe bab 10 babu. Aku kudu nransfer VIP saka master menyang salah siji saka babu lan nyambung kabeh babu liyane menyang. Pira konsol sing kudu dibukak, pirang-pirang komando simultaneous aku mlebu ... Aku kudu ngenteni nganti jam 3 esuk, mbusak beban saka kabeh budak kajaba loro, nggawe mesin pisanan metu saka loro master, langsung masang mesin kapindho. kanggo iku, supaya masang kabeh abdi liyane kanggo master anyar lan bali mbukak. Sakabèhé, elek ...

Kepiye cara kerjane Orkestra nalika dadi mode failover? Iki paling gampang digambarake kanthi conto kahanan sing pengin nggawe master sing luwih kuat, mesin sing luwih modern tinimbang saiki.

Tokoh nuduhake tengah proses. Apa sing wis ditindakake nganti saiki? Kita ngandika sing kita wanted kanggo nggawe sawetara abdi master anyar, Orchestrator wiwit mung nyambungake kabeh babu liyane menyang, karo master anyar tumindak minangka mesin transit. Kanthi skema iki, ora ana kesalahan, kabeh budak kerja, Orchestrator mbusak VIP saka master lawas, pindhah menyang sing anyar, nggawe read_only = 0 lan lali babagan master lawas. Kabeh! Downtime layanan kita yaiku wektu transfer VIP, yaiku 2-3 detik.

Semono uga kanggo dina iki, matur nuwun kanggo kabeh. Bakal ana artikel kapindho babagan Orchestrator. Ing film Soviet misuwur "Garage", siji karakter ngandika, "Aku ora bakal pindhah ing pengintaian karo wong!" Dadi, Orkestra, aku arep melu pengintaian!

Source: www.habr.com