Setiap proyek besar dimulai dengan beberapa server. Pada awalnya ada satu server DB, kemudian budak ditambahkan ke dalamnya untuk menskalakan pembacaan. Dan kemudian - berhenti! Ada satu tuan, tetapi ada banyak budak; jika salah satu budak pergi, maka semuanya akan baik-baik saja, tetapi jika master pergi, itu akan menjadi buruk: downtime, admin mencoba menaikkan server. Apa yang harus dilakukan? Pesan master. Rekan saya Pavel sudah menulis tentang ini , saya tidak akan mengulanginya. Sebaliknya, saya akan memberi tahu Anda mengapa Anda pasti membutuhkan Orchestrator untuk MySQL!
Mari kita mulai dengan pertanyaan utama: “Bagaimana kita akan mengalihkan kode ke mesin baru ketika master keluar?”
- Saya paling suka skema dengan VIP (Virtual IP), kita akan membicarakannya di bawah. Ini yang paling sederhana dan paling jelas, meskipun memiliki batasan yang jelas: master yang akan kita pesan harus berada di segmen L2 dengan mesin baru, yaitu kita bisa melupakan DC kedua. Dan, secara kekeluargaan, jika Anda mengikuti aturan bahwa L2 yang besar itu jahat, karena L2 hanya per rak, dan L3 ada di antara rak, dan skema seperti itu memiliki lebih banyak batasan.
- Anda dapat menulis nama DNS dalam kode dan mengatasinya melalui /etc/hosts. Faktanya, tidak akan ada penyelesaian. Keuntungan dari skema ini: tidak ada batasan yang khas dari metode pertama, yaitu dimungkinkan untuk mengatur cross-DC. Namun kemudian muncul pertanyaan yang jelas: seberapa cepat kami dapat mengirimkan perubahan ke /etc/hosts melalui Puppet-Ansible?
- Anda dapat sedikit mengubah metode kedua: instal cache DNS di semua server web, yang melaluinya kode akan masuk ke database master. Anda dapat mengatur TTL 60 untuk entri ini di DNS. Tampaknya jika diterapkan dengan benar, metodenya bagus.
- Skema dengan penemuan layanan, menyiratkan penggunaan Konsul dan lain-lain.
- Pilihan yang menarik dengan . Anda perlu merutekan semua lalu lintas ke MySQL melalui ProxySQL; ProxySQL sendiri dapat menentukan siapa masternya. Omong-omong, Anda dapat membaca tentang salah satu opsi untuk menggunakan produk ini di saya .
Penulis Orchestrator, yang bekerja di Github, pertama-tama mengimplementasikan skema pertama dengan VIP, dan kemudian mengubahnya menjadi skema dengan konsul.
Tata letak infrastruktur yang umum:
Saya akan segera menjelaskan situasi nyata yang perlu dipertimbangkan:
- Alamat VIP tidak boleh didaftarkan dalam konfigurasi di server mana pun. Mari kita bayangkan sebuah situasi: master melakukan boot ulang, dan saat sedang memuat, Orchestrator masuk ke mode failover dan menjadikan salah satu budak menjadi master; lalu tuan tua itu bangkit, dan sekarang VIP ada di dua mobil. Ini buruk.
- Untuk orkestrator, Anda perlu menulis skrip untuk memanggil master lama dan master baru. Pada master lama Anda perlu menjalankan ifdown, dan pada master baru – ifup vip. Sebaiknya sertakan juga dalam skrip ini bahwa jika terjadi kegagalan, port pada sakelar master lama dimatikan begitu saja untuk menghindari perpecahan otak.
- Setelah Orchestrator memanggil skrip Anda untuk terlebih dahulu menghapus VIP dan/atau mematikan port pada switch, dan kemudian memanggil skrip peningkatan VIP pada master baru, jangan lupa untuk menggunakan perintah arping untuk memberi tahu semua orang bahwa VIP baru sekarang Di Sini.
- Semua budak harus memiliki read_only=1, dan segera setelah Anda mempromosikan budak ke master, budak tersebut seharusnya memiliki read_only=0.
- Jangan lupa bahwa budak mana pun yang kita pilih untuk ini bisa menjadi master (Orchestrator memiliki seluruh mekanisme preferensi budak mana yang harus dipertimbangkan sebagai calon master baru, yang mana yang kedua, dan budak mana yang harus tidak boleh dipilih sama sekali dalam kondisi apapun master). Jika budak menjadi tuan, maka beban budak akan tetap di atasnya dan beban tuan akan bertambah, hal ini harus diperhitungkan.
Mengapa Anda memerlukan Orchestrator jika Anda tidak memilikinya?
- Orchestrator memiliki antarmuka grafis yang sangat ramah pengguna yang menampilkan seluruh topologi (lihat gambar di bawah).
- Orchestrator dapat melacak budak mana yang tertinggal, dan di mana replikasi umumnya rusak (kami memiliki skrip yang dilampirkan ke Orchestrator untuk mengirim SMS).
- Orchestrator memberi tahu Anda budak mana yang memiliki GTID yang salah.
Antarmuka Orkestrator:
Apa itu GTID yang salah?
Ada dua persyaratan utama agar Orchestrator dapat bekerja:
- GTID semu harus diaktifkan di semua mesin di cluster MySQL; kami telah mengaktifkan GTID.
- Perlu ada satu jenis binlog di mana-mana, Anda dapat menggunakan pernyataan. Kami memiliki konfigurasi di mana master dan sebagian besar budak memiliki Row, dan dua secara historis tetap dalam mode Campuran. Akibatnya, Orchestrator tidak ingin menghubungkan budak-budak ini dengan tuan baru.
Ingatlah bahwa hal terpenting dalam seorang budak produksi adalah konsistensinya dengan tuannya! Jika Anda mengaktifkan ID Transaksi Global (GTID) pada master dan slave, Anda dapat menggunakan fungsi gtid_subset untuk mengetahui apakah permintaan perubahan data yang sama benar-benar telah dijalankan pada mesin ini. Anda dapat membaca lebih lanjut tentang ini .
Dengan demikian, Orchestrator menunjukkan kepada Anda melalui GTID yang salah bahwa ada transaksi di slave yang tidak ada di master. Mengapa ini terjadi?
- Read_only=1 tidak diaktifkan pada budak, seseorang terhubung dan menyelesaikan permintaan untuk mengubah data.
- Super_read_only=1 tidak diaktifkan di slave, lalu admin, karena membingungkan server, masuk dan menjalankan permintaan di sana.
- Jika Anda memperhitungkan kedua poin sebelumnya, maka ada satu trik lagi: di MySQL, permintaan untuk menyiram binlog juga masuk ke binlog, jadi pada pembilasan pertama, kesalahan GTID akan muncul pada master dan semua budak. Bagaimana cara menghindarinya? Perona-5.7.25-28 memperkenalkan pengaturan binlog_skip_flush_commands=1, yang melarang penulisan flush ke binlogs. Ada yang sudah mapan di situs web mysql.com .
Izinkan saya meringkas semua hal di atas. Jika Anda belum ingin menggunakan Orchestrator dalam mode failover, alihkan ke mode observasi. Maka Anda akan selalu melihat peta interaksi mesin MySQL dan informasi visual tentang jenis replikasi apa yang ada di setiap mesin, apakah budak tertinggal, dan yang paling penting, seberapa konsisten mereka dengan master!
Pertanyaan yang jelas adalah: “Bagaimana seharusnya Orchestrator bekerja?” Dia harus memilih master baru dari budak saat ini, dan kemudian menyambungkan kembali semua budak ke sana (untuk itulah GTID diperlukan; jika Anda menggunakan mekanisme lama dengan binlog_name dan binlog_pos, maka alihkan budak dari master saat ini ke yang baru. tidak mungkin!). Sebelum kami memiliki Orchestrator, saya harus melakukan semua ini secara manual. Master lama digantung karena pengontrol Adaptec yang bermasalah; ia memiliki sekitar 10 budak. Saya perlu mentransfer VIP dari master ke salah satu budak dan menghubungkan kembali semua budak lainnya ke sana. Berapa banyak konsol yang harus saya buka, berapa banyak perintah simultan yang saya masukkan... Saya harus menunggu sampai jam 3 pagi, lepaskan beban dari semua budak kecuali dua, jadikan mesin pertama dari dua master, segera pasang mesin kedua ke sana, jadi lampirkan semua budak lainnya ke master baru dan kembalikan bebannya. Secara keseluruhan, mengerikan...
Bagaimana cara kerja Orchestrator saat masuk ke mode failover? Hal ini paling mudah diilustrasikan dengan contoh situasi di mana kita ingin menjadikan seorang master mesin yang lebih bertenaga dan lebih modern daripada yang kita miliki sekarang.
Gambar tersebut menunjukkan bagian tengah proses. Apa yang sudah dilakukan sampai saat ini? Kami mengatakan bahwa kami ingin menjadikan beberapa budak sebagai master baru, Orchestrator mulai menghubungkan kembali semua budak lainnya ke dalamnya, dengan master baru bertindak sebagai mesin transit. Dengan skema ini, tidak ada kesalahan yang terjadi, semua budak berfungsi, Orchestrator menghapus VIP dari master lama, mentransfernya ke master baru, membuat read_only=0 dan melupakan master lama. Semua! Downtime layanan kami adalah waktu transfer VIP yaitu 2-3 detik.
Itu saja untuk hari ini, terima kasih semuanya. Akan ada artikel kedua tentang Orchestrator segera. Dalam film terkenal Soviet “Garage,” salah satu karakter berkata, “Saya tidak akan melakukan pengintaian dengannya!” Jadi, Orchestrator, saya akan ikut dengan Anda dalam pengintaian!
Sumber: www.habr.com