Orchestrator untuk MySQL: mengapa anda tidak boleh membina projek toleran kesalahan tanpanya

Mana-mana projek besar bermula dengan beberapa pelayan. Pada mulanya terdapat satu pelayan DB, kemudian hamba telah ditambah kepadanya untuk skala bacaan. Dan kemudian - berhenti! Terdapat satu tuan, tetapi terdapat banyak hamba; jika salah seorang hamba pergi, maka semuanya akan baik-baik saja, tetapi jika tuan pergi, ia akan menjadi buruk: downtime, admin cuba menaikkan pelayan. Apa nak buat? Rizab tuan. Rakan sekerja saya Pavel sudah menulis tentang perkara ini artikel, saya tidak akan mengulanginya. Sebaliknya, saya akan memberitahu anda mengapa anda pasti memerlukan Orchestrator untuk MySQL!

Mari kita mulakan dengan soalan utama: "Bagaimanakah kita akan menukar kod kepada mesin baharu apabila tuan pergi?"

• Saya paling suka skim dengan VIP (IP Maya), kita akan bercakap mengenainya di bawah. Ia adalah yang paling mudah dan paling jelas, walaupun ia mempunyai had yang jelas: tuan yang akan kami tempah mesti berada dalam segmen L2 dengan mesin baru, iaitu, kita boleh melupakan DC kedua. Dan, dengan cara yang baik, jika anda mengikuti peraturan bahawa L2 yang besar adalah jahat, kerana L2 hanya untuk setiap rak, dan L3 berada di antara rak, dan skema sedemikian mempunyai lebih banyak sekatan.
• Anda boleh menulis nama DNS dalam kod dan menyelesaikannya melalui /etc/hosts. Malah, tidak akan ada penyelesaian. Kelebihan skema: tidak ada ciri batasan kaedah pertama, iaitu, adalah mungkin untuk mengatur cross-DC. Tetapi kemudian persoalan yang jelas timbul: seberapa cepat kita boleh menyampaikan perubahan kepada /etc/hosts melalui Puppet-Ansible?
• Anda boleh menukar kaedah kedua sedikit: pasang DNS caching pada semua pelayan web, di mana kod itu akan pergi ke pangkalan data induk. Anda boleh menetapkan TTL 60 untuk entri ini dalam DNS. Nampaknya jika dilaksanakan dengan betul, kaedahnya bagus.
• Skim dengan penemuan perkhidmatan, membayangkan penggunaan Konsul dan lain-lain.
• Pilihan yang menarik dengan ProxySQL. Anda perlu menghalakan semua trafik ke MySQL melalui ProxySQL; ProxySQL sendiri boleh menentukan siapa tuannya. Dengan cara ini, anda boleh membaca tentang salah satu pilihan untuk menggunakan produk ini dalam saya artikel.

Pengarang Orchestrator, bekerja di Github, mula-mula melaksanakan skim pertama dengan VIP, dan kemudian menukarnya kepada skim dengan konsul.

Susun atur infrastruktur biasa:

Saya akan segera menerangkan situasi jelas yang perlu diambil kira:

• Alamat VIP tidak boleh didaftarkan dalam konfigurasi pada mana-mana pelayan. Mari kita bayangkan satu situasi: tuan itu but semula, dan semasa ia sedang dimuatkan, Orkestra masuk ke mod failover dan menjadikan salah seorang hamba sebagai tuan; kemudian tuan tua bangkit, dan kini VIP menaiki dua buah kereta. Ini tidak baik.
• Untuk orkestra, anda perlu menulis skrip untuk memanggil tuan lama dan tuan baru. Pada tuan lama anda perlu menjalankan ifdown, dan pada tuan baru - ifup vip. Adalah lebih baik untuk memasukkan juga dalam skrip ini bahawa sekiranya berlaku kegagalan, port pada suis tuan lama dimatikan semata-mata untuk mengelakkan sebarang splitbrain.
• Selepas Orchestrator memanggil skrip anda untuk mengalih keluar VIP dan/atau memadamkan port pada suis, dan kemudian memanggil skrip menaikkan VIP pada master baharu, jangan lupa gunakan arahan arping untuk memberitahu semua orang bahawa VIP baharu kini di sini.
• Semua hamba sepatutnya mempunyai read_only=1, dan sebaik sahaja anda mempromosikan hamba kepada tuan, ia sepatutnya read_only=0.
• Jangan lupa bahawa mana-mana hamba yang telah kita pilih untuk ini boleh menjadi tuan (Orchestrator mempunyai mekanisme keutamaan keseluruhan untuk hamba mana yang perlu dipertimbangkan sebagai calon tuan baru di tempat pertama, yang di tempat kedua, dan hamba mana yang harus tidak dipilih sama sekali dalam apa jua keadaan tuan). Jika hamba menjadi tuan, maka beban hamba akan kekal di atasnya dan beban tuan akan ditambah, ini mesti diambil kira.

Mengapa anda memerlukan Orkestra jika anda tidak mempunyainya?

• Orchestrator mempunyai antara muka grafik yang sangat mesra pengguna yang memaparkan keseluruhan topologi (lihat tangkapan skrin di bawah).
• Orchestrator boleh menjejaki hamba yang ketinggalan, dan tempat replikasi secara amnya telah dipecahkan (kami mempunyai skrip yang dilampirkan pada Orchestrator untuk menghantar SMS).
• Orkestra memberitahu anda hamba mana yang mempunyai kesalahan GTID.

Antara Muka Orkestra:

Apakah kesalahan GTID?

Terdapat dua keperluan utama untuk Orchestrator berfungsi:

• GTID pseudo perlu didayakan pada semua mesin dalam kelompok MySQL; kami telah mendayakan GTID.
• Ia adalah perlu bahawa terdapat satu jenis binlog di mana-mana, anda boleh menggunakan pernyataan. Kami mempunyai konfigurasi di mana tuan dan kebanyakan hamba mempunyai Row, dan dua mengikut sejarah kekal dalam mod Campuran. Akibatnya, Orkestra tidak mahu menghubungkan hamba-hamba ini kepada tuan baru.

Ingat bahawa perkara yang paling penting dalam hamba pengeluaran ialah konsistensinya dengan tuan! Jika anda telah mendayakan ID Transaksi Global (GTID) pada tuan dan hamba anda, maka anda boleh menggunakan fungsi gtid_subset untuk mengetahui sama ada permintaan yang sama untuk perubahan data sebenarnya telah dilaksanakan pada mesin ini. Anda boleh membaca lebih lanjut mengenai ini di sini.

Oleh itu, Orchestrator menunjukkan kepada anda melalui kesalahan GTID bahawa terdapat transaksi pada hamba yang bukan pada tuan. Kenapa ini terjadi?

• Read_only=1 tidak didayakan pada hamba, seseorang menyambung dan menyelesaikan permintaan untuk menukar data.
• Super_read_only=1 tidak didayakan pada hamba, maka pentadbir, setelah mengelirukan pelayan, masuk dan melaksanakan permintaan di sana.
• Jika anda mengambil kira kedua-dua mata sebelumnya, maka terdapat satu lagi helah: dalam MySQL, permintaan untuk membuang binlog juga pergi ke binlog, jadi pada siram pertama, kesalahan GTID akan muncul pada tuan dan semua hamba. Bagaimana untuk mengelakkan ini? Perona-5.7.25-28 memperkenalkan tetapan binlog_skip_flush_commands=1, yang melarang menulis flush ke binlog. Terdapat yang mantap di laman web mysql.com pepijat.

Biar saya ringkaskan semua perkara di atas. Jika anda tidak mahu menggunakan Orchestrator dalam mod failover lagi, kemudian letakkannya dalam mod pemerhatian. Kemudian anda akan sentiasa mempunyai di hadapan mata anda peta interaksi mesin MySQL dan maklumat visual tentang jenis replikasi pada setiap mesin, sama ada hamba ketinggalan, dan yang paling penting, betapa konsistennya mereka dengan tuan!

Soalan yang jelas ialah: "Bagaimanakah Orkestra harus berfungsi?" Dia mesti memilih tuan baharu daripada hamba semasa, dan kemudian menyambung semula semua hamba kepadanya (inilah yang diperlukan GTID; jika anda menggunakan mekanisme lama dengan binlog_name dan binlog_pos, kemudian menukar hamba daripada tuan semasa kepada yang baharu adalah mustahil!). Sebelum kami mempunyai Orkestra, saya pernah melakukan semua ini secara manual. Tuan tua itu tergantung kerana pengawal Adaptec buggy; ia mempunyai kira-kira 10 hamba. Saya perlu memindahkan VIP daripada tuan kepada salah seorang hamba dan menyambung semula semua hamba lain kepadanya. Berapa banyak konsol yang saya perlu buka, berapa banyak arahan serentak yang saya masukkan ... Saya terpaksa menunggu sehingga 3 pagi, keluarkan beban dari semua hamba kecuali dua, buat mesin pertama daripada dua master, serta-merta pasang mesin kedua kepadanya, jadi pasangkan semua hamba yang lain kepada tuan baru dan kembalikan beban itu. Secara keseluruhan, dahsyat...

Bagaimanakah Orchestrator berfungsi apabila ia masuk ke mod failover? Ini paling mudah digambarkan dengan contoh situasi di mana kita ingin menjadikan tuan sebagai mesin yang lebih berkuasa dan lebih moden daripada yang kita ada sekarang.

Rajah menunjukkan pertengahan proses. Apakah yang telah dilakukan sehingga ke tahap ini? Kami berkata bahawa kami ingin menjadikan beberapa hamba sebagai tuan baharu, Orkestra mula menyambung semula semua hamba lain kepadanya, dengan tuan baharu bertindak sebagai mesin transit. Dengan skema ini, tiada ralat berlaku, semua hamba berfungsi, Orchestrator mengeluarkan VIP daripada tuan lama, memindahkannya kepada yang baharu, membuat read_only=0 dan melupakan tuan lama. Semua! Masa henti perkhidmatan kami ialah masa pemindahan VIP, iaitu 2-3 saat.

Itu sahaja untuk hari ini, terima kasih semua. Akan ada artikel kedua tentang Orkestra tidak lama lagi. Dalam filem Soviet yang terkenal "Garage," seorang watak berkata, "Saya tidak akan pergi meninjau dengannya!" Jadi, Orkestra, saya akan pergi bersama anda untuk meninjau!

Sumber: www.habr.com