Di Citymobil kami menggunakan pangkalan data MySQL sebagai storan data berterusan utama kami. Kami mempunyai beberapa kluster pangkalan data untuk pelbagai perkhidmatan dan tujuan.

Ketersediaan induk yang berterusan adalah penunjuk kritikal prestasi keseluruhan sistem dan bahagian individunya. Pemulihan kluster automatik sekiranya berlaku kegagalan induk sangat mengurangkan masa tindak balas insiden dan masa henti sistem. Dalam artikel ini, saya akan melihat reka bentuk ketersediaan tinggi (HA) untuk kluster MySQL berdasarkan MySQL Orchestrator dan alamat IP maya (VIP).

Penyelesaian HA berdasarkan VIP

Pertama, saya akan memberitahu anda secara ringkas tentang sistem storan data kami.

Kami menggunakan skema replikasi klasik dengan satu induk boleh akses tulis dan berbilang replika baca sahaja. Kelompok boleh mengandungi induk perantaraan - nod yang merupakan replika dan induk untuk orang lain. Pelanggan mengakses replika melalui HAProxy, yang membolehkan pengagihan beban yang sekata dan penskalaan yang mudah. Penggunaan HAProxy adalah disebabkan oleh sebab sejarah, dan kami sedang dalam proses berhijrah ke ProxySQL.

Replikasi dilakukan dalam mod separa segerak berdasarkan GTID. Ini bermakna sekurang-kurangnya satu replika mesti log transaksi sebelum ia dianggap berjaya. Mod replikasi ini menyediakan keseimbangan optimum antara prestasi dan keselamatan data sekiranya berlaku kegagalan nod induk. Pada asasnya semua perubahan dipindahkan daripada induk kepada replika menggunakan Row Based Replication (RBR), tetapi beberapa nod mungkin mempunyai mixed binlog format.

Orkestra mengemas kini keadaan topologi kluster secara berkala, menganalisis maklumat yang diterima, dan jika masalah timbul, ia boleh melancarkan prosedur pemulihan automatik. Pembangun bertanggungjawab untuk prosedur itu sendiri, kerana ia boleh dilaksanakan dengan cara yang berbeza: berdasarkan VIP, DNS, menggunakan perkhidmatan penemuan perkhidmatan atau mekanisme yang ditulis sendiri.

Satu cara mudah untuk memulihkan induk jika gagal ialah menggunakan alamat VIP terapung.

Apa yang anda perlu tahu tentang penyelesaian ini sebelum bergerak ke hadapan:

VIP ialah alamat IP yang tidak dikaitkan dengan antara muka rangkaian fizikal tertentu. Jika nod gagal atau semasa penyelenggaraan berjadual, kami boleh menukar VIP kepada sumber lain dengan masa henti yang minimum.
Membebaskan dan mengeluarkan alamat IP maya adalah operasi yang murah dan pantas.
Untuk bekerja dengan VIP, anda memerlukan akses kepada pelayan melalui SSH, atau penggunaan utiliti khas, sebagai contoh, keepalived.

Mari lihat kemungkinan masalah dengan wizard kami dan bayangkan bagaimana mekanisme pemulihan automatik harus berfungsi.

Kesambungan rangkaian kepada induk telah hilang, atau masalah telah timbul pada peringkat perkakasan, dan pelayan tidak tersedia

Orkestra mengemas kini topologi kluster, setiap replika melaporkan bahawa induk tidak tersedia. Orkestra memulakan proses memilih replika yang sesuai untuk peranan tuan baharu dan memulakan pemulihan.
Kami cuba mengeluarkan VIP daripada tuan lama - tidak berjaya.
Replika bertukar kepada peranan tuan. Topologi sedang dibina semula.
Menambah antara muka rangkaian baharu dengan VIP. Memandangkan tidak mungkin untuk mengalih keluar VIP, kami mula menghantar permintaan secara berkala di latar belakang ARP percuma. Jenis permintaan/tindak balas ini membolehkan anda mengemas kini jadual pemetaan alamat IP dan MAC pada suis yang disambungkan, dengan itu memberitahu anda bahawa VIP kami telah berpindah. Ini meminimumkan kemungkinan split brain apabila memulangkan tuan lama.
Semua sambungan baharu segera dialihkan kepada tuan baharu. Sambungan lama gagal dan panggilan berulang ke pangkalan data dibuat pada peringkat aplikasi.

Pelayan beroperasi dalam mod biasa, kegagalan berlaku pada peringkat DBMS

Algoritma adalah serupa dengan kes sebelumnya: mengemas kini topologi dan memulakan proses pemulihan. Memandangkan pelayan tersedia, kami berjaya melepaskan VIP pada tuan lama, memindahkannya kepada yang baharu dan menghantar beberapa permintaan ARP. Kemungkinan pengembalian tuan lama seharusnya tidak menjejaskan kluster yang dibina semula dan pengendalian aplikasi.

Masalah lain

Kegagalan replika atau induk perantaraan tidak memimpin kepada tindakan automatik dan memerlukan campur tangan manual.

Antara muka rangkaian maya sentiasa ditambah buat sementara waktu, iaitu selepas but semula pelayan, VIP tidak ditetapkan secara automatik. Setiap contoh pangkalan data bermula dalam mod baca sahaja secara lalai, orkestra secara automatik menukar induk baharu untuk menulis dan cuba memasang read only pada tuan lama. Tindakan ini bertujuan untuk mengurangkan kemungkinan split brain.

Masalah mungkin timbul semasa proses pemulihan, yang juga harus dimaklumkan melalui UI orkestra sebagai tambahan kepada alat pemantauan standard. Kami telah mengembangkan REST API dengan menambahkan ciri ini (PR sedang disemak).

Gambar rajah am larutan HA dibentangkan di bawah.

Memilih tuan baru

Orkestra cukup bijak dan cuba memilih replika yang paling sesuai sebagai sarjana baharu mengikut kriteria berikut:

replika ketinggalan di belakang tuan;
Versi induk dan replika MySQL;
jenis replikasi (RBR, SBR atau campuran);
lokasi di pusat data yang sama atau berbeza;
ketersediaan errant GTID — urus niaga yang telah dilaksanakan pada replika dan bukan pada induk;
peraturan pemilihan tersuai juga diambil kira.

Tidak setiap isyarat adalah calon yang ideal untuk sarjana. Contohnya, replika boleh digunakan untuk membuat sandaran data, atau pelayan mempunyai konfigurasi perkakasan yang lebih lemah. Orkestra menyokong peraturan manual yang boleh anda gunakan untuk menyesuaikan pilihan pilihan calon anda daripada yang paling disukai kepada yang diabaikan.

Masa tindak balas dan pemulihan

Sekiranya berlaku insiden, adalah penting untuk meminimumkan masa henti sistem, jadi mari kita pertimbangkan parameter MySQL yang mempengaruhi penciptaan dan pengemaskinian topologi kluster oleh orkestra:

slave_net_timeout — bilangan saat semasa replika menunggu data baharu atau isyarat degupan jantung tiba daripada induk sebelum sambungan diiktiraf sebagai hilang dan disambung semula. Semakin rendah nilai, semakin cepat replika dapat menentukan bahawa komunikasi dengan tuan terputus. Kami menetapkan nilai ini kepada 5 saat.
MASTER_CONNECT_RETRY — bilangan saat antara percubaan penyambungan semula. Sekiranya berlaku masalah rangkaian, nilai yang rendah untuk parameter ini akan membolehkan penyambungan semula cepat dan menghalang proses pemulihan kluster daripada bermula. Nilai yang disyorkan ialah 1 saat.
MASTER_RETRY_COUNT — bilangan maksimum percubaan penyambungan semula.
MASTER_HEARTBEAT_PERIOD — selang dalam beberapa saat selepas itu tuan menghantar isyarat degupan jantung. Lalai kepada separuh nilai slave_net_timeout.

Pilihan Orkestra:

DelayMasterPromotionIfSQLThreadNotUpToDate - jika sama true, maka peranan induk tidak akan digunakan pada replika calon sehingga urutan SQL replika telah menyelesaikan semua transaksi yang tidak digunakan daripada Log Geganti. Kami menggunakan pilihan ini untuk mengelakkan kehilangan transaksi apabila semua replika calon ketinggalan.
InstancePollSeconds — kekerapan membina dan mengemas kini topologi.
RecoveryPollSeconds - kekerapan analisis topologi. Jika masalah dikesan, pemulihan topologi dimulakan. ini pemalar, sama dengan 1 saat.

Setiap nod kluster ditinjau oleh orkestra setiap sekali InstancePollSeconds detik Apabila masalah dikesan, keadaan kluster terpaksa dikemas kini, dan kemudian keputusan muktamad dibuat untuk melakukan pemulihan. Dengan bereksperimen dengan pangkalan data dan parameter orkestra yang berbeza, kami dapat mengurangkan masa tindak balas dan pemulihan kepada 30 saat.

Tempat ujian

Kami mula menguji skim HA dengan pembangunan tempatan bangku ujian dan pelaksanaan selanjutnya dalam persekitaran ujian dan pengeluaran. Pendirian tempatan diautomatikkan sepenuhnya berdasarkan Docker dan membolehkan anda bereksperimen dengan konfigurasi orkestra dan rangkaian, skala kluster daripada 2-3 pelayan kepada beberapa dozen dan menjalankan latihan dalam persekitaran yang selamat.

Semasa latihan, kami memilih salah satu kaedah emulasi masalah: serta-merta menembak master menggunakan kill -9, tamatkan proses dengan lembut dan hentikan pelayan (docker-compose stop), simulasi masalah rangkaian menggunakan iptables -j REJECT atau iptables -j DROP. Kami mengharapkan hasil berikut:

orkestra akan mengesan masalah dengan induk dan mengemas kini topologi dalam masa tidak lebih daripada 10 saat;
prosedur pemulihan akan bermula secara automatik: konfigurasi rangkaian akan berubah, peranan tuan akan berpindah ke replika, topologi akan dibina semula;
tuan baharu akan menjadi boleh ditulis, replika langsung tidak akan hilang semasa proses pembinaan semula;
data akan mula ditulis kepada tuan baru dan direplikasi;
Jumlah masa pemulihan tidak akan melebihi 30 saat.

Seperti yang anda ketahui, sistem mungkin berkelakuan berbeza dalam persekitaran ujian dan pengeluaran disebabkan oleh perkakasan dan konfigurasi rangkaian yang berbeza, perbezaan dalam beban sintetik dan sebenar, dsb. Oleh itu, kami secara berkala menjalankan latihan dalam keadaan sebenar, menyemak cara sistem berkelakuan apabila sambungan rangkaian terputus atau bahagian individunya terdegradasi. Pada masa hadapan, kami mahu membina infrastruktur yang sama sepenuhnya untuk kedua-dua persekitaran dan mengautomasikan ujiannya.

Penemuan

Kesihatan nod sistem storan utama adalah salah satu tugas utama SRE dan pasukan operasi. Pelaksanaan orkestra dan penyelesaian HA berdasarkan VIP membolehkan kami mencapai keputusan berikut:

pengesanan boleh dipercayai masalah dengan topologi kluster pangkalan data;
respons automatik dan pantas kepada insiden berkaitan induk, mengurangkan masa henti sistem.

Walau bagaimanapun, penyelesaian itu mempunyai batasan dan keburukannya:

menskalakan skim HA ke beberapa pusat data akan memerlukan satu rangkaian L2 di antara mereka;
Sebelum menetapkan VIP pada master baru, kita perlu melepaskannya pada master lama. Prosesnya berurutan, yang meningkatkan masa pemulihan;
melepaskan VIP memerlukan akses SSH ke pelayan, atau sebarang kaedah lain untuk memanggil prosedur jauh. Memandangkan pelayan atau pangkalan data mengalami masalah yang menyebabkan proses pemulihan, kami tidak dapat memastikan bahawa pengalihan keluar VIP akan selesai dengan jayanya. Dan ini boleh membawa kepada kemunculan dua pelayan dengan alamat IP maya yang sama dan masalah split brain.

Untuk mengelakkan split brain, anda boleh menggunakan kaedah tersebut STONITH (“Tembak Nod Lain Di Kepala”), yang mengasingkan atau melumpuhkan nod masalah sepenuhnya. Terdapat cara lain untuk melaksanakan ketersediaan kluster tinggi: gabungan VIP dan DNS, penemuan perkhidmatan dan perkhidmatan proksi, replikasi segerak dan kaedah lain yang mempunyai kelemahan dan kelebihan tersendiri.

Saya bercakap tentang pendekatan kami untuk mencipta kluster failover MySQL. Ia mudah untuk dilaksanakan dan menyediakan tahap kebolehpercayaan yang boleh diterima dalam keadaan semasa. Apabila keseluruhan sistem secara amnya dan infrastruktur khususnya berkembang, pendekatan ini sudah pasti akan berkembang.

Sumber: www.habr.com

Orkestra dan VIP sebagai penyelesaian HA untuk kluster MySQL