Di CityMobile, kami menggunakan database MySQL sebagai penyimpanan utama untuk data persisten. Kami memiliki beberapa cluster basis data untuk berbagai layanan dan keperluan.

Ketersediaan wizard yang konstan adalah indikator penting kesehatan seluruh sistem dan bagian-bagiannya masing-masing. Pemulihan gugus otomatis jika terjadi kegagalan penyihir sangat mengurangi waktu respons kejadian dan waktu henti sistem. Pada artikel ini, saya akan melihat cluster HA MySQL berdasarkan pada MySQL Orchestrator dan alamat IP virtual (VIP).

Solusi VIP HA

Pertama, saya akan berbicara singkat tentang seperti apa sistem penyimpanan data kami.

Kami menggunakan skema replikasi klasik dengan satu wisaya hanya-tulis dan banyak replika hanya-baca. Cluster dapat berisi master perantara - simpul yang merupakan replika dan master untuk orang lain. Klien mengakses replika melalui HAProxy, yang memungkinkan distribusi muatan merata dan skalabilitas mudah. Penggunaan HAProxy adalah karena alasan historis, dan sekarang kami sedang dalam proses migrasi ke ProxySQL.

Replikasi semi-sinkron berdasarkanGTID. Ini berarti bahwa setidaknya satu replika harus menulis transaksi ke log sebelum dianggap berhasil. Mode replikasi ini memberikan keseimbangan optimal antara kinerja dan keamanan data jika terjadi kegagalan pada simpul utama. Pada dasarnya, semua perubahan ditransfer dari master ke replika menggunakan Row Based Replication (RBR), tetapi beberapa node mungkin memiliki mixed binlog format.

Orkestrator secara berkala memperbarui keadaan topologi klaster, menganalisis informasi yang diterima dan, jika ada masalah, dapat memulai 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 mandiri.

Salah satu cara termudah untuk memulihkan penyihir jika gagal adalah dengan menggunakan alamat VIP mengambang.

Apa yang perlu Anda ketahui tentang solusi ini sebelum melanjutkan:

VIP adalah alamat IP yang tidak terikat dengan antarmuka jaringan fisik tertentu. Ketika sebuah node gagal atau selama pekerjaan yang dijadwalkan, kita dapat mengganti VIP ke sumber daya lain dengan downtime minimal.
Melepaskan dan mengeluarkan alamat IP virtual adalah operasi yang murah dan cepat.
Untuk bekerja dengan VIP memerlukan akses ke server melalui SSH, atau penggunaan alat khusus, misalnya keepalived.

Kami akan mempertimbangkan kemungkinan masalah dengan master kami dan membayangkan bagaimana mekanisme pemulihan otomatis seharusnya bekerja.

Konektivitas jaringan ke master telah hilang, atau masalah telah terjadi pada tingkat perangkat keras, dan server tidak tersedia

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
Semua koneksi baru segera dialihkan ke master baru. Koneksi lama gagal, panggilan berulang dilakukan ke basis data di tingkat aplikasi.

Server beroperasi dalam mode normal, kegagalan terjadi pada level DBMS

Algoritma ini mirip dengan kasus sebelumnya: memperbarui topologi dan memulai proses pemulihan. Karena server tersedia, kami berhasil merilis VIP pada master lama, mentransfernya ke yang baru dan mengirim beberapa permintaan ARP. Kemungkinan kembalinya wizard lama tidak akan memengaruhi cluster yang dibangun kembali dan pengoperasian aplikasi.

Masalah lainnya

Kegagalan replika atau master perantara tidak mengarah ke tindakan otomatis dan memerlukan intervensi manual.

Antarmuka jaringan virtual selalu ditambahkan sementara, yaitu, setelah me-reboot server VIP tidak secara otomatis ditetapkan. Setiap instance dari database diluncurkan secara default dalam mode read-only, orkestrator secara otomatis beralih master baru untuk merekam dan mencoba untuk menginstal read onlypada master lama. Tindakan-tindakan ini bertujuan mengurangi kemungkinan split brain.

Selama proses pemulihan, masalah mungkin timbul, yang juga harus diberitahukan melalui UI orkestra selain alat pemantauan standar. Kami telah memperluas REST API dengan menambahkan fitur ini ( PR saat ini sedang dipertimbangkan).

Skema umum dari solusi HA disajikan di bawah ini.

Memilih Wizard Baru

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

lag replika dari master;
Panduan MySQL dan versi replika;
jenis replikasi (RBR, SBR, atau campuran);
lokasi di satu atau beberapa pusat data;
ketersediaan errant GTID- transaksi yang dilakukan pada replika dan tidak ada pada master;
aturan pemilihan khusus juga diperhitungkan.

Tidak setiap replika adalah kandidat ideal untuk peran master. Misalnya, replika dapat digunakan untuk membuat cadangan data, atau server memiliki konfigurasi perangkat keras yang lebih lemah. Orkestrator mendukung aturan manual yang dengannya Anda dapat menyesuaikan preferensi Anda untuk memilih kandidat dari yang paling disukai untuk diabaikan.

Waktu Respons dan Pemulihan

Dalam hal terjadi insiden, penting untuk meminimalkan waktu henti sistem, oleh karena itu, kami mempertimbangkan parameter MySQL yang memengaruhi konstruksi dan pemutakhiran topologi klaster oleh orkestra:

slave_net_timeout- jumlah detik selama replika menunggu data baru atau sinyal detak jantung dari master sebelum koneksi dikenali hilang dan koneksi kembali dilakukan. Semakin rendah nilainya, semakin cepat replika akan dapat menentukan bahwa koneksi dengan master terputus. Kami menetapkan nilai ini ke 5 detik.
MASTER_CONNECT_RETRY- jumlah detik antara upaya koneksi ulang. Jika terjadi masalah jaringan, nilai rendah dari parameter ini akan memungkinkan Anda untuk menyambung kembali dengan cepat dan mencegah dimulainya proses pemulihan cluster. Nilai yang disarankan adalah 1 detik.
MASTER_RETRY_COUNT - Jumlah upaya maksimum untuk menyambung kembali.
MASTER_HEARTBEAT_PERIOD- Interval dalam detik setelah mana master mengirimkan sinyal detak jantung. Standarnya adalah setengah dari nilai slave_net_timeout.

Opsi orkestra:

DelayMasterPromotionIfSQLThreadNotUpToDate- jika sama true, maka peran wizard tidak akan diterapkan pada kandidat replika sampai aliran SQL replika menyelesaikan semua transaksi yang belum diterapkan dari Relay Log. Kami menggunakan opsi ini agar tidak kehilangan transaksi ketika semua calon kandidat ketinggalan.
InstancePollSeconds - frekuensi membangun dan memperbarui topologi.
RecoveryPollSeconds- frekuensi analisis topologi. Jika masalah terdeteksi, pemulihan topologi dimulai. Ini adalah konstan sama dengan 1 detik.

Setiap node cluster disurvei oleh orkestrator sekali setiap InstancePollSecondsdetik. Ketika masalah terdeteksi, keadaan klaster diperbarui secara paksa , dan kemudian keputusan akhir dibuat untuk melakukan pemulihan. Dengan bereksperimen dengan berbagai parameter dari basis data dan orkestra, kami dapat mengurangi durasi respons dan pemulihan hingga 30 detik.

Test stand

Kami mulai menguji skema HA dengan mengembangkan bangku tes lokal dan selanjutnya menerapkannya dalam lingkungan uji dan pertempuran. Stand lokal sepenuhnya otomatis berdasarkan Docker dan memungkinkan Anda untuk bereksperimen dengan konfigurasi orkestra dan jaringan, skala cluster dari 2-3 server menjadi beberapa puluhan dan melakukan latihan di lingkungan yang aman.

Selama latihan, kami memilih salah satu metode untuk meniru masalah: langsung memotret wizard kill -9, selesaikan proses dan hentikan server ( docker-compose stop), simulasikan masalah jaringan dengan iptables -j REJECTatau iptables -j DROP. Kami mengharapkan hasil ini:

orkestra akan mendeteksi masalah dengan master dan memperbarui topologi dalam waktu tidak lebih dari 10 detik;
prosedur pemulihan akan secara otomatis dimulai: konfigurasi jaringan akan berubah, peran wizard akan pergi ke replika, topologi akan dibangun kembali;
master baru akan tersedia untuk direkam, replika langsung tidak akan hilang dalam proses pembangunan kembali;
data akan mulai ditulis ke master baru dan direplikasi;
total waktu pemulihan tidak akan lebih dari 30 detik.

Seperti yang Anda ketahui, suatu sistem dapat berperilaku berbeda dalam lingkungan pengujian dan produksi karena konfigurasi perangkat keras dan jaringan yang berbeda, perbedaan dalam beban sintetis dan nyata, dll. Oleh karena itu, kami secara berkala melakukan latihan dalam kondisi nyata, memeriksa bagaimana sistem berperilaku jika kehilangan konektivitas jaringan atau degradasi bagian-bagian individualnya. Di masa depan, kami ingin membangun infrastruktur yang benar-benar identik untuk lingkungan dan mengotomatiskan pengujiannya.

temuan

Operabilitas simpul utama sistem penyimpanan adalah salah satu tugas utama tim dan operasi SRE. Pengenalan orkestra dan solusi HA berdasarkan VIP memungkinkan untuk mencapai hasil berikut:

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

Namun, solusinya memiliki keterbatasan dan kelemahan:

penskalaan skema HA ke beberapa pusat data akan membutuhkan jaringan L2 tunggal di antara mereka;
sebelum Anda menetapkan VIP ke master baru, kita perlu membebaskannya pada yang lama. Prosesnya berurutan, yang meningkatkan waktu pemulihan;
VIP SSH- , . , , , VIP . IP- split brain.

Untuk menghindarinya split brain, Anda dapat menggunakan metode STONITH ("Shoot The Other Node In The Head"), yang sepenuhnya mengisolasi atau memutus simpul masalah. Ada cara lain untuk mengimplementasikan ketersediaan tinggi dari kluster: kombinasi VIP dan DNS, penemuan layanan dan layanan proxy, replikasi sinkron, dan metode lain yang memiliki kelemahan dan kelebihannya.

Saya berbicara tentang pendekatan kami untuk membuat cluster failover MySQL. Mudah diimplementasikan dan memberikan tingkat keandalan yang dapat diterima di lingkungan saat ini. Dengan pengembangan seluruh sistem secara keseluruhan dan infrastruktur khususnya, pendekatan ini tidak diragukan lagi akan berkembang.

Orchestrator dan VIP sebagai solusi HA untuk cluster MySQL