Di Citymobil kami menggunakan database MySQL sebagai penyimpanan data persisten utama kami. Kami memiliki beberapa cluster database untuk berbagai layanan dan tujuan.

Ketersediaan master yang konstan merupakan indikator penting dari kinerja seluruh sistem dan bagian-bagiannya. Pemulihan klaster otomatis jika terjadi kegagalan master sangat mengurangi waktu respons insiden dan waktu henti sistem. Pada artikel ini, saya akan melihat desain ketersediaan tinggi (HA) untuk cluster MySQL berdasarkan Pengatur MySQL dan alamat IP virtual (VIP).

Solusi HA berdasarkan VIP

Pertama, saya akan memberi tahu Anda secara singkat apa itu sistem penyimpanan data kami.

Kami menggunakan skema replikasi klasik dengan satu master yang dapat diakses tulis dan beberapa replika hanya baca. Sebuah cluster dapat berisi master perantara - sebuah node yang merupakan replika dan master bagi yang lain. Klien mengakses replika melalui HAProxy, yang memungkinkan pemerataan beban dan penskalaan yang mudah. Penggunaan HAProxy karena alasan historis, dan kami sedang dalam proses migrasi ke ProxySQL.

Replikasi dilakukan dalam mode semi-sinkron berdasarkan GTID. Artinya setidaknya satu replika harus mencatat transaksi sebelum dianggap berhasil. Mode replikasi ini memberikan keseimbangan optimal antara kinerja dan keamanan data jika terjadi kegagalan node master. Pada dasarnya semua perubahan ditransfer dari master ke replika menggunakan Row Based Replication (RBR), tetapi beberapa node mungkin memilikinya mixed binlog format.

Orkestra secara berkala memperbarui keadaan topologi cluster, menganalisis informasi yang diterima, dan jika timbul masalah, ia dapat meluncurkan prosedur pemulihan otomatis. Pengembang bertanggung jawab atas prosedur itu sendiri, karena dapat diimplementasikan dengan berbagai cara: berdasarkan VIP, DNS, menggunakan layanan penemuan layanan, atau mekanisme yang ditulis sendiri.

Salah satu cara sederhana untuk memulihkan master jika gagal adalah dengan menggunakan alamat VIP mengambang.

Apa yang perlu Anda ketahui tentang solusi ini sebelum melanjutkan:

VIP adalah alamat IP yang tidak terkait dengan antarmuka jaringan fisik tertentu. Jika sebuah node gagal atau selama pemeliharaan terjadwal, kami dapat mengalihkan VIP ke sumber daya lain dengan waktu henti minimal.
Membebaskan dan mengeluarkan alamat IP virtual adalah operasi yang murah dan cepat.
Untuk bekerja dengan VIP, Anda memerlukan akses ke server melalui SSH, atau penggunaan utilitas khusus, misalnya, keepalived.

Mari kita lihat kemungkinan masalah dengan wizard kita dan bayangkan bagaimana mekanisme pemulihan otomatis seharusnya bekerja.

Konektivitas jaringan ke master hilang, atau muncul masalah di tingkat perangkat keras, dan server tidak tersedia

Orkestra memperbarui topologi cluster, setiap replika melaporkan bahwa master tidak tersedia. Orkestra memulai proses pemilihan replika yang cocok untuk peran master baru dan memulai pemulihan.
Kami mencoba menghapus VIP dari master lama - tidak berhasil.
Replika beralih ke peran master. Topologi sedang dibangun kembali.
Menambahkan antarmuka jaringan baru dengan VIP. Karena VIP tidak dapat dihapus, kami mulai mengirimkan permintaan secara berkala di latar belakang ARP gratis. Jenis permintaan/respons ini memungkinkan Anda memperbarui tabel pemetaan alamat IP dan MAC pada sakelar yang terhubung, sehingga memberi tahu Anda bahwa VIP kami telah pindah. Ini meminimalkan kemungkinannya split brain saat mengembalikan tuan lama.
Semua koneksi baru segera dialihkan ke master baru. Koneksi lama gagal dan panggilan berulang ke database dilakukan di tingkat aplikasi.

Server beroperasi dalam mode normal, terjadi kegagalan di tingkat DBMS

Algoritmenya mirip dengan kasus sebelumnya: memperbarui topologi dan memulai proses pemulihan. Karena server tersedia, kami berhasil melepaskan VIP pada master lama, mentransfernya ke master baru, dan mengirimkan beberapa permintaan ARP. Kemungkinan kembalinya master lama seharusnya tidak mempengaruhi cluster yang dibangun kembali dan pengoperasian aplikasi.

Masalah lainnya

Kegagalan replika atau master perantara tidak memimpin untuk tindakan otomatis dan memerlukan intervensi manual.

Antarmuka jaringan virtual selalu ditambahkan sementara, artinya, setelah server di-boot ulang, VIP tidak ditetapkan secara otomatis. Setiap instance database dimulai dalam mode read-only secara default, orkestrator secara otomatis mengalihkan master baru untuk menulis dan mencoba menginstal read only pada tuan tua. Tindakan ini bertujuan untuk mengurangi kemungkinan tersebut split brain.

Masalah mungkin timbul selama proses pemulihan, yang juga harus diberitahukan melalui UI orkestrator selain alat pemantauan standar. Kami telah memperluas REST API dengan menambahkan fitur ini (PR sedang ditinjau).

Diagram umum solusi HA disajikan di bawah ini.

Memilih master baru

Orkestra cukup pintar dan mencoba memilih replika yang paling cocok sebagai master baru dengan kriteria sebagai berikut:

replikanya tertinggal dari masternya;
Versi master dan replika MySQL;
jenis replikasi (RBR, SBR atau campuran);
lokasi di pusat data yang sama atau berbeda;
ketersediaan errant GTID — transaksi yang dieksekusi pada replika dan bukan pada master;
aturan pemilihan khusus juga diperhitungkan.

Tidak semua isyarat merupakan kandidat ideal untuk menjadi master. Misalnya, replika dapat digunakan untuk membuat cadangan data, atau server memiliki konfigurasi perangkat keras yang lebih lemah. Pemimpin orkestra mendukung aturan manual yang dengannya Anda dapat menyesuaikan preferensi pemilihan kandidat Anda dari yang paling disukai hingga diabaikan.

Respon dan waktu pemulihan

Jika terjadi insiden, penting untuk meminimalkan waktu henti sistem, jadi mari kita pertimbangkan parameter MySQL yang memengaruhi pembuatan dan pembaruan topologi cluster oleh orkestrator:

slave_net_timeout — jumlah detik selama replika menunggu data baru atau sinyal detak jantung tiba dari master sebelum koneksi dikenali sebagai hilang dan tersambung kembali. Semakin rendah nilainya, semakin cepat replika dapat menentukan bahwa komunikasi dengan master terputus. Kami menetapkan nilai ini menjadi 5 detik.
MASTER_CONNECT_RETRY — jumlah detik antara upaya penyambungan kembali. Jika terjadi masalah jaringan, nilai yang rendah untuk parameter ini akan memungkinkan koneksi ulang yang cepat dan mencegah proses pemulihan cluster dimulai. Nilai yang disarankan adalah 1 detik.
MASTER_RETRY_COUNT — jumlah maksimum upaya penyambungan kembali.
MASTER_HEARTBEAT_PERIOD — interval dalam detik setelah master mengirimkan sinyal detak jantung. Defaultnya adalah setengah nilai slave_net_timeout.

Opsi orkestrator:

DelayMasterPromotionIfSQLThreadNotUpToDate - jika sama true, maka peran master tidak akan diterapkan pada kandidat replika hingga thread SQL replika tersebut menyelesaikan semua transaksi yang belum diterapkan dari Log Relai. Kami menggunakan opsi ini untuk menghindari kehilangan transaksi ketika semua kandidat replika tertinggal.
InstancePollSeconds — frekuensi membangun dan memperbarui topologi.
RecoveryPollSeconds — frekuensi analisis topologi. Jika masalah terdeteksi, pemulihan topologi dimulai. Ini konstan, sama dengan 1 detik.

Setiap node cluster disurvei oleh orkestrator setiap satu kali InstancePollSeconds detik Ketika masalah terdeteksi, status cluster akan dipaksa diperbarui, dan kemudian keputusan akhir dibuat untuk melakukan pemulihan. Dengan bereksperimen dengan parameter database dan orkestrator yang berbeda, kami dapat mengurangi waktu respons dan pemulihan hingga 30 detik.

Tempat uji coba

Kami mulai menguji skema HA dengan pengembangan lokal bangku tes dan implementasi lebih lanjut dalam lingkungan pengujian dan produksi. Stand lokal sepenuhnya otomatis berdasarkan Docker dan memungkinkan Anda bereksperimen dengan konfigurasi orkestrator dan jaringan, menskalakan cluster dari 2-3 server menjadi beberapa lusin, dan melakukan latihan di lingkungan yang aman.

Selama latihan, kami memilih salah satu metode emulasi masalah: langsung menembak master menggunakan kill -9, hentikan proses secara perlahan dan hentikan server (docker-compose stop), simulasikan masalah jaringan menggunakan iptables -j REJECT или iptables -j DROP. Kami mengharapkan hasil sebagai berikut:

orkestrator akan mendeteksi masalah dengan master dan memperbarui topologi dalam waktu tidak lebih dari 10 detik;
prosedur pemulihan akan dimulai secara otomatis: konfigurasi jaringan akan berubah, peran master akan diteruskan ke replika, topologi akan dibangun kembali;
master baru akan dapat ditulisi, replika aktif tidak akan hilang selama proses pembangunan kembali;
data akan mulai ditulis ke master baru dan direplikasi;
Total waktu pemulihan tidak lebih dari 30 detik.

Seperti yang Anda ketahui, sistem mungkin berperilaku berbeda dalam lingkungan pengujian dan produksi karena perbedaan konfigurasi perangkat keras dan jaringan, perbedaan beban sintetis dan nyata, dll. Oleh karena itu, kami secara berkala melakukan latihan dalam kondisi nyata, memeriksa bagaimana sistem berperilaku ketika konektivitas jaringan terputus atau bagian-bagiannya terdegradasi. Di masa depan, kami ingin membangun infrastruktur yang sepenuhnya identik untuk kedua lingkungan dan mengotomatiskan pengujiannya.

Temuan

Kesehatan node sistem penyimpanan utama adalah salah satu tugas utama SRE dan tim operasi. Penerapan solusi orkestrator dan HA berdasarkan VIP memungkinkan kami mencapai hasil berikut:

deteksi masalah yang andal dengan topologi cluster database;
respons otomatis dan cepat terhadap insiden terkait master, sehingga mengurangi waktu henti sistem.

Namun, solusi tersebut mempunyai keterbatasan dan kelemahan:

penskalaan skema HA ke beberapa pusat data akan memerlukan satu jaringan L2 di antara mereka;
Sebelum menetapkan VIP pada master baru, kita perlu melepaskannya pada master lama. Prosesnya berurutan, sehingga meningkatkan waktu pemulihan;
melepaskan VIP memerlukan akses SSH ke server, atau metode lain untuk memanggil prosedur jarak jauh. Karena server atau database mengalami masalah yang menyebabkan proses pemulihan, kami tidak dapat memastikan penghapusan VIP akan berhasil diselesaikan. Dan ini dapat menyebabkan munculnya dua server dengan alamat IP virtual yang sama dan menimbulkan masalah split brain.

Menghindari split brain, Anda dapat menggunakan metode ini STONIT (“Tembak Node Lain Di Kepala”), yang sepenuhnya mengisolasi atau menonaktifkan node yang bermasalah. Ada cara lain untuk mengimplementasikan ketersediaan tinggi cluster: kombinasi VIP dan DNS, penemuan layanan dan layanan proxy, replikasi sinkron, dan metode lain yang memiliki kekurangan dan kelebihannya masing-masing.

Saya berbicara tentang pendekatan kami untuk membuat cluster failover MySQL. Mudah diterapkan dan memberikan tingkat keandalan yang dapat diterima dalam kondisi saat ini. Seiring dengan berkembangnya keseluruhan sistem pada umumnya dan infrastruktur pada khususnya, pendekatan ini pasti akan berkembang.

Sumber: www.habr.com

Orchestrator dan VIP sebagai solusi HA untuk cluster MySQL