Orchestrator untuk MySQL: mengapa proyek gagal-aman tidak dapat dibangun tanpanya

Setiap proyek besar dimulai dengan sepasang server. Pertama, ada satu server DB, kemudian budak ditambahkan ke dalamnya untuk skala pembacaan. Dan di sini - berhenti! Satu tuan, tetapi banyak budak; jika salah satu budak pergi, maka semuanya akan baik-baik saja, tetapi jika master pergi, itu akan menjadi buruk: downtime, admin di sabun meningkatkan server. Apa yang harus dilakukan? Cadangan master. Rekan saya Pavel sudah menulis artikel tentang ini , saya tidak akan mengulanginya. Sebaliknya, saya akan memberi tahu Anda mengapa Anda benar-benar membutuhkan Orkestra untuk MySQL!

Mari kita mulai dengan pertanyaan utama: "Bagaimana kita akan mengganti kode ke mesin baru ketika wizard pergi?"

• Saya paling suka skema dengan VIP (Virtual IP), kami akan membicarakannya di bawah ini. Ini adalah yang paling sederhana dan paling jelas, meskipun memiliki batasan yang jelas: master, yang akan kami cadangan, harus berada di segmen L2 dengan mesin baru, yaitu, Anda bisa melupakan DC kedua. Dan, dengan cara yang baik, jika Anda mengikuti aturan bahwa L2 besar itu jahat, karena L2 hanya per rak, dan di antara rak L3, dan skema semacam itu bahkan memiliki batasan lebih.
• Anda dapat mendaftarkan nama DNS dalam kode dan menyelesaikannya melalui / etc / hosts. Bahkan, tidak akan ada resolusi. Keuntungan skema: tidak ada batasan karakteristik dari metode pertama, yaitu, Anda juga dapat mengatur lintas-DC. Tetapi kemudian muncul pertanyaan yang jelas, seberapa cepat melalui Puppet-Ansible kita dapat mengirimkan perubahan ke / etc / hosts.
• Anda dapat mengubah metode kedua sedikit: pada semua server web kami menaruh caching DNS, di mana kode akan masuk ke master database. Anda dapat mendaftarkan TTL 60 untuk entri DNS ini. Tampaknya dengan implementasi yang tepat, metode ini baik.
• Skema dengan penemuan layanan, yang melibatkan penggunaan Konsul dan lain-lain.
• Opsi yang menarik dengan ProxySQL . Penting untuk membungkus semua lalu lintas ke MySQL melalui ProxySQL, ProxySQL dapat menentukan siapa masternya sekarang. Ngomong-ngomong, tentang salah satu opsi untuk menggunakan produk ini dapat ditemukan di artikel saya .

Penulis Orchestrator, saat mengerjakan Github, pertama mengimplementasikan skema pertama dengan VIP, dan kemudian mendesain ulangnya dengan c consul.

Skema infrastruktur khas:

Saya akan segera menggambarkan situasi yang jelas untuk dipertimbangkan:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• Semua budak harus memiliki read_only = 1, dan segera setelah Anda mempromosikan slave ke master, itu seharusnya read_only = 0.
• Jangan lupa bahwa budak mana pun yang telah kami pilih untuk ini dapat menjadi master (Orchestrator memiliki seluruh mekanisme preferensi, yang mana budak harus dianggap sebagai calon master baru, yang mana yang kedua, dan yang budak mana yang tidak boleh dipilih sama sekali dalam keadaan apa pun) menguasai). Jika budak menjadi master, maka beban budak akan tetap di atasnya dan beban master akan ditambahkan, ini harus diperhitungkan.

Mengapa Anda benar-benar membutuhkan Orkestrator jika Anda tidak memilikinya?

• Orchestrator memiliki antarmuka grafis yang sangat user-friendly yang menampilkan seluruh topologi (lihat screenshot di bawah).
• Orchestrator dapat melacak budak mana yang ada di belakang, dan di mana replikasi umumnya rusak (kami memiliki skrip untuk mengirim SMS ke Orchestrator).
• Orchestrator memberi tahu Anda slide mana yang memiliki galat eritan GTID.

Antarmuka orkestra:

Apa itu GTID errant?

Ada dua persyaratan dasar bagi Orkestra untuk bekerja:

• Penting bahwa pseudo GTID diaktifkan di semua mesin di kluster MySQL, kami mengaktifkan GTID.
• Penting bahwa di mana-mana ada satu jenis binlog, Anda dapat membuat pernyataan. Kami memiliki konfigurasi di mana Row berada di master dan pada sebagian besar budak, dan mode Mixed tetap secara historis pada dua. Akibatnya, Orchestrator tidak mau menghubungkan budak-budak ini dengan master baru.

Ingatlah bahwa hal terpenting dalam seorang budak produksi adalah konsistensinya dengan tuan! Jika Anda memiliki Global Transaction ID (GTID) diaktifkan pada master dan slave, Anda dapat menggunakan fungsi gtid_subset untuk mengetahui apakah permintaan perubahan data yang sama benar-benar dieksekusi pada mesin ini. Baca lebih lanjut tentang ini di sini .

Jadi, Orchestrator menunjukkan kepada Anda melalui kesalahan erat GTID bahwa ada transaksi pada slave yang tidak ada di wizard. Kenapa itu terjadi?

• Read_only = 1 tidak diaktifkan pada slave, seseorang terhubung dan mengeksekusi permintaan untuk perubahan data.
• Super_read_only = 1 tidak diaktifkan pada slave, maka administrator, setelah mencampuradukkan server, masuk dan mengeksekusi permintaan di sana.
• Jika Anda memperhitungkan kedua paragraf sebelumnya, ada satu trik lagi: di MySQL, permintaan untuk flush binlogs juga jatuh ke dalam binlog, jadi ketika Anda flush untuk pertama kalinya, galaksi GTID akan muncul di wizard dan pada semua budak. Bagaimana cara menghindarinya? Dalam perona-5.7.25-28, pengaturan binlog_skip_flush_commands = 1 muncul, yang melarang penulisan flush ke binlog. Ada bug di mysql.com .

Saya merangkum semua hal di atas. Jika Anda belum ingin menggunakan Orchestrator dalam mode failover, masukkan ke mode pengawasan. Maka Anda akan selalu memiliki di depan mata Anda peta interaksi mesin MySQL dan informasi yang jelas tentang jenis replikasi pada setiap mesin, apakah budak di belakang, dan yang paling penting - seberapa banyak konsistensi yang mereka miliki dengan master!

Pertanyaan yang jelas adalah: "Bagaimana seharusnya Orchestrator bekerja?" Dia harus memilih master baru dari slave saat ini, dan kemudian menghubungkan kembali semua slave ke sana (inilah gunanya GTID; jika Anda menggunakan mekanisme lama dengan binlog_name dan binlog_pos, maka mengalihkan slave dari master saat ini ke yang baru tidak mungkin!). Sebelum Orchestrator datang kepada kami, saya pernah harus melakukan semua ini secara manual. Master tua jatuh karena controller Adaptec buggy, itu memiliki sekitar 10 budak. Saya perlu mentransfer VIP dari master ke salah satu budak dan menghubungkan kembali semua budak lain ke sana. Berapa banyak konsol yang harus saya buka, berapa banyak perintah simultan untuk masuk ... Saya harus menunggu sampai jam 3 pagi, menghapus beban dari semua budak, kecuali dua, membuat mobil pertama dari dua tuan, segera menghubungkan mobil kedua ke sana,oleh karena itu, ambil semua budak lain ke master baru dan kembalikan beban. Secara umum, kengerian ...

Bagaimana cara kerja Orchestrator ketika memasuki mode failover? Ini paling mudah ditunjukkan oleh contoh situasi di mana kami ingin menjadikan master mesin yang lebih kuat, lebih modern daripada sekarang.

Gambar tersebut menunjukkan tengah proses. Apa yang sudah dilakukan sampai titik ini? Kami mengatakan bahwa kami ingin membuat semacam budak menjadi master baru, Orchestrator baru saja mulai menghubungkan kembali semua budak lain ke dalamnya, dan master baru bertindak sebagai mesin transit. Dengan skema ini, kesalahan tidak terjadi, semua budak berfungsi, Orkestra menghapus VIP dari master lama, mentransfer ke yang baru, membuat read_only = 0 dan lupa tentang master lama. Semua! Waktu henti layanan kami adalah waktu transfer VIP, itu adalah 2-3 detik.

Itu saja untuk hari ini, terima kasih semuanya. Segera akan ada artikel kedua tentang Orchestrator. Dalam film Soviet yang terkenal "The Garage," seorang pahlawan berkata, "Aku tidak akan pergi ke intelijen dengannya!" Jadi, Orchestrator, saya akan pergi bersama Anda untuk mencari!