Orchestrator ສໍາລັບ MySQL: ເປັນຫຍັງທ່ານບໍ່ສາມາດສ້າງໂຄງການທີ່ມີຄວາມທົນທານຕໍ່ຄວາມຜິດພາດໂດຍບໍ່ມີມັນ

ໂຄງການຂະຫນາດໃຫຍ່ໃດໆທີ່ເລີ່ມຕົ້ນດ້ວຍເຄື່ອງແມ່ຂ່າຍສອງສາມອັນ. ທໍາອິດມີເຄື່ອງແມ່ຂ່າຍ DB ຫນຶ່ງ, ຫຼັງຈາກນັ້ນຂ້າທາດໄດ້ຖືກເພີ່ມໃສ່ມັນເພື່ອຂະຫຍາຍການອ່ານ. ແລະຫຼັງຈາກນັ້ນ - ຢຸດ! ມີ​ນາຍ​ຄົນ​ໜຶ່ງ, ແຕ່​ມີ​ຂ້າ​ໃຊ້​ຫຼາຍ​ຄົນ; ຖ້າຫາກວ່າຫນຶ່ງຂອງສໍາລອງອອກ, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງຈະດີ, ແຕ່ຖ້າຫາກວ່າແມ່ບົດອອກ, ມັນຈະບໍ່ດີ: downtime, admins ກໍາລັງພະຍາຍາມຍົກສູງບົດບາດເຄື່ອງແມ່ຂ່າຍ. ຈະເຮັດແນວໃດ? ຈອງແມ່ບົດ. ເພື່ອນຮ່ວມງານຂອງຂ້ອຍ Pavel ຂຽນກ່ຽວກັບເລື່ອງນີ້ແລ້ວ ບົດຄວາມ, ຂ້າພະເຈົ້າຈະບໍ່ເຮັດຊ້ໍາອີກ. ແທນທີ່ຈະ, ຂ້ອຍຈະບອກເຈົ້າວ່າເປັນຫຍັງເຈົ້າຕ້ອງການ Orchestrator ສໍາລັບ MySQL!

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຄໍາຖາມຕົ້ນຕໍ: "ພວກເຮົາຈະປ່ຽນລະຫັດໄປຫາເຄື່ອງຈັກໃຫມ່ແນວໃດເມື່ອແມ່ບົດອອກ?"

• ຂ້ອຍມັກໂຄງການທີ່ມີ VIP (Virtual IP) ທີ່ສຸດ, ພວກເຮົາຈະເວົ້າກ່ຽວກັບມັນຂ້າງລຸ່ມນີ້. ມັນງ່າຍດາຍທີ່ສຸດແລະຊັດເຈນທີ່ສຸດ, ເຖິງແມ່ນວ່າມັນມີຂໍ້ຈໍາກັດທີ່ຊັດເຈນ: ແມ່ບົດທີ່ພວກເຮົາຈະສະຫງວນຕ້ອງຢູ່ໃນສ່ວນ L2 ກັບເຄື່ອງຈັກໃຫມ່, ນັ້ນແມ່ນ, ພວກເຮົາສາມາດລືມກ່ຽວກັບ DC ທີສອງ. ແລະ, ໃນທາງທີ່ເປັນມິດ, ຖ້າທ່ານປະຕິບັດຕາມກົດລະບຽບວ່າ L2 ຂະຫນາດໃຫຍ່ແມ່ນຊົ່ວ, ເພາະວ່າ L2 ແມ່ນພຽງແຕ່ຕໍ່ rack, ແລະ L3 ແມ່ນຢູ່ລະຫວ່າງ racks, ແລະໂຄງການດັ່ງກ່າວມີຂໍ້ຈໍາກັດຫຼາຍກວ່າເກົ່າ.
• ທ່ານສາມາດຂຽນຊື່ DNS ໃນລະຫັດແລະແກ້ໄຂມັນຜ່ານ /etc/hosts. ໃນຄວາມເປັນຈິງ, ຈະບໍ່ມີການແກ້ໄຂ. ປະໂຫຍດຂອງໂຄງການ: ບໍ່ມີລັກສະນະຈໍາກັດຂອງວິທີການທໍາອິດ, ນັ້ນແມ່ນ, ມັນເປັນໄປໄດ້ທີ່ຈະຈັດຕັ້ງຂ້າມ DC. ແຕ່ຫຼັງຈາກນັ້ນຄໍາຖາມທີ່ຊັດເຈນເກີດຂື້ນ: ພວກເຮົາສາມາດສົ່ງການປ່ຽນແປງໄປຫາ /etc/hosts ຜ່ານ Puppet-Ansible ໄດ້ໄວເທົ່າໃດ?
• ທ່ານສາມາດປ່ຽນວິທີການທີສອງເລັກນ້ອຍ: ຕິດຕັ້ງ DNS caching ໃນເຄື່ອງແມ່ຂ່າຍເວັບທັງຫມົດ, ໂດຍຜ່ານລະຫັດຈະໄປຫາຖານຂໍ້ມູນຕົ້ນສະບັບ. ທ່ານສາມາດຕັ້ງ TTL 60 ສໍາລັບການປ້ອນນີ້ໃນ DNS. ມັນເບິ່ງຄືວ່າຖ້າປະຕິບັດຢ່າງຖືກຕ້ອງ, ວິທີການແມ່ນດີ.
• ໂຄງ​ການ​ທີ່​ມີ​ການ​ຄົ້ນ​ພົບ​ການ​ບໍ​ລິ​ການ​, ຫມາຍ​ເຖິງ​ການ​ນໍາ​ໃຊ້​ກົງ​ສຸນ​ແລະ​ອື່ນໆ​.
• ເປັນທາງເລືອກທີ່ຫນ້າສົນໃຈກັບ ProxySQL. ທ່ານຈໍາເປັນຕ້ອງໄດ້ສົ່ງການຈະລາຈອນທັງຫມົດໄປຫາ MySQL ຜ່ານ ProxySQL ຕົວຂອງມັນເອງສາມາດກໍານົດຜູ້ທີ່ເປັນແມ່ບົດ. ໂດຍວິທີທາງການ, ທ່ານສາມາດອ່ານກ່ຽວກັບຫນຶ່ງໃນທາງເລືອກໃນການໃຊ້ຜະລິດຕະພັນນີ້ໃນຂອງຂ້ອຍ ບົດຄວາມ.

ຜູ້ຂຽນຂອງ Orchestrator, ເຮັດວຽກຢູ່ໃນ Github, ທໍາອິດໄດ້ປະຕິບັດໂຄງການທໍາອິດກັບ VIP, ແລະຫຼັງຈາກນັ້ນປ່ຽນເປັນໂຄງການທີ່ມີ consul.

ໂຄງຮ່າງພື້ນຖານທົ່ວໄປ:

ຂ້າພະເຈົ້າຈະອະທິບາຍທັນທີທັນໃດສະຖານະການທີ່ຈະແຈ້ງທີ່ຕ້ອງໄດ້ຮັບການພິຈາລະນາ:

• ທີ່ຢູ່ VIP ບໍ່ຄວນລົງທະບຽນໃນການຕັ້ງຄ່າໃນເຄື່ອງແມ່ຂ່າຍໃດໆ. ຂໍໃຫ້ຈິນຕະນາການສະຖານະການ: ແມ່ບົດ rebooted, ແລະໃນຂະນະທີ່ມັນກໍາລັງໂຫລດ, Orchestrator ໄດ້ເຂົ້າໄປໃນໂຫມດລົ້ມເຫລວແລະເຮັດໃຫ້ຫນຶ່ງໃນສໍາລອງເປັນຕົ້ນສະບັບ; ຫຼັງຈາກນັ້ນ, ຕົ້ນສະບັບເກົ່າໄດ້ເພີ່ມຂຶ້ນ, ແລະໃນປັດຈຸບັນ VIP ແມ່ນຢູ່ໃນສອງລົດ. ນີ້ແມ່ນບໍ່ດີ.
• ສໍາລັບນັກດົນຕີ, ທ່ານຈະຕ້ອງຂຽນບົດສໍາລັບການເອີ້ນນາຍເກົ່າແລະນາຍໃຫມ່. ໃນແມ່ບົດເກົ່າເຈົ້າຈໍາເປັນຕ້ອງແລ່ນ ifdown, ແລະໃນແມ່ບົດໃຫມ່ - ifup vip. ມັນຈະເປັນການດີທີ່ຈະລວມຢູ່ໃນສະຄິບນີ້ວ່າໃນກໍລະນີຂອງການລົ້ມເຫລວ, ພອດຢູ່ໃນສະວິດຂອງຕົ້ນສະບັບເກົ່າແມ່ນຖືກປິດພຽງແຕ່ເພື່ອຫຼີກເວັ້ນການແຍກສະຫມອງໃດໆ.
• ຫຼັງຈາກ Orchestrator ໄດ້ເອີ້ນ script ຂອງເຈົ້າເພື່ອເອົາ VIP ແລະ / ຫຼື extinguish port ໃນ switch, ແລະຫຼັງຈາກນັ້ນເອີ້ນວ່າ script ການລ້ຽງ VIP ໃນແມ່ບົດໃຫມ່, ຢ່າລືມໃຊ້ຄໍາສັ່ງ arping ເພື່ອບອກທຸກຄົນວ່າ VIP ໃຫມ່ແມ່ນໃນປັດຈຸບັນ. ທີ່ນີ້.
• ຂ້າທາດທັງໝົດຄວນມີ read_only=1, ແລະທັນທີທີ່ທ່ານສົ່ງເສີມທາດໃຫ້ນາຍ, ມັນຄວນຈະມີ read_only=0.
• ຢ່າລືມວ່າສໍາລອງໃດໆທີ່ພວກເຮົາເລືອກສໍາລັບການນີ້ສາມາດກາຍເປັນນາຍ (Orchestrator ມີກົນໄກຄວາມມັກທັງຫມົດສໍາລັບສໍາລອງທີ່ຈະພິຈາລະນາເປັນຜູ້ສະຫມັກສໍາລັບນາຍໃຫມ່ໃນສະຖານທີ່ທໍາອິດ, ທີ່ສອງ, ແລະສໍາລອງໃດຄວນ. ບໍ່​ໄດ້​ຮັບ​ການ​ຄັດ​ເລືອກ​ຢູ່​ໃນ​ທຸກ​ສະ​ຖາ​ນະ​ການ​ແມ່​ບົດ​)​. ຖ້າຂ້າທາດກາຍເປັນນາຍ, ຫຼັງຈາກນັ້ນ, ການໂຫຼດຂອງທາດຈະຍັງຄົງຢູ່ໃນມັນແລະການໂຫຼດຂອງນາຍຫນ້າຈະຖືກເພີ່ມ, ນີ້ຕ້ອງໄດ້ຮັບການພິຈາລະນາ.

ເປັນຫຍັງເຈົ້າຕ້ອງການ Orchestrator ຖ້າເຈົ້າບໍ່ມີ?

• Orchestrator ມີການໂຕ້ຕອບຮູບພາບທີ່ເປັນມິດກັບຜູ້ໃຊ້ຫຼາຍທີ່ສະແດງ topology ທັງຫມົດ (ເບິ່ງຮູບຫນ້າຈໍຂ້າງລຸ່ມນີ້).
• Orchestrator ສາ​ມາດ​ຕິດ​ຕາມ​ວ່າ​ຂ້າ​ໃຊ້​ໃດ​ທີ່​ຊັກ​ຊ້າ​, ແລະ​ໂດຍ​ທົ່ວ​ໄປ​ແລ້ວ​ການ​ຈໍາ​ລອງ​ໄດ້​ແຍກ​ອອກ (ພວກ​ເຮົາ​ມີ​ສະ​ຄິບ​ຕິດ​ກັບ Orchestrator ສໍາ​ລັບ​ການ​ສົ່ງ SMS​)​.
• Orchestrator ບອກທ່ານວ່າຂ້າທາດໃດທີ່ມີຄວາມຜິດພາດ GTID.

ການໂຕ້ຕອບຂອງ Orchestrator:

GTID ຜິດພາດແມ່ນຫຍັງ?

ມີສອງຄວາມຕ້ອງການຕົ້ນຕໍສໍາລັບ Orchestrator ເຮັດວຽກ:

• ມັນເປັນສິ່ງຈໍາເປັນທີ່ pseudo GTID ຖືກເປີດໃຊ້ໃນທຸກເຄື່ອງຈັກໃນກຸ່ມ MySQL;
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຕ້ອງມີປະເພດຂອງ binlogs ຢູ່ທົ່ວທຸກແຫ່ງ, ທ່ານສາມາດນໍາໃຊ້ຄໍາຖະແຫຼງການ. ພວກ​ເຮົາ​ມີ​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ນາຍ​ແລະ​ຂ້າ​ໃຊ້​ຫຼາຍ​ທີ່​ສຸດ​ມີ Row​, ແລະ​ສອງ​ປະ​ຫວັດ​ສາດ​ຍັງ​ຄົງ​ຢູ່​ໃນ​ຮູບ​ແບບ​ປະ​ສົມ​. ດັ່ງນັ້ນ, Orchestrator ພຽງແຕ່ບໍ່ຕ້ອງການທີ່ຈະເຊື່ອມຕໍ່ສໍາລອງເຫຼົ່ານີ້ກັບແມ່ບົດໃຫມ່.

ຈົ່ງຈື່ໄວ້ວ່າສິ່ງທີ່ສໍາຄັນທີ່ສຸດໃນສໍາລອງການຜະລິດແມ່ນຄວາມສອດຄ່ອງຂອງມັນກັບແມ່ບົດ! ຖ້າທ່ານມີ ID ການເຮັດທຸລະກໍາທົ່ວໂລກ (GTID) ເປີດໃຊ້ທັງແມ່ແລະສໍາລອງຂອງເຈົ້າ, ຫຼັງຈາກນັ້ນທ່ານສາມາດນໍາໃຊ້ຟັງຊັນ gtid_subset ເພື່ອຊອກຫາວ່າຄໍາຮ້ອງຂໍດຽວກັນສໍາລັບການປ່ຽນແປງຂໍ້ມູນໄດ້ຖືກປະຕິບັດຢູ່ໃນເຄື່ອງເຫຼົ່ານີ້. ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ ທີ່ນີ້.

ດັ່ງນັ້ນ, Orchestrator ສະແດງໃຫ້ທ່ານເຫັນຜ່ານ GTID errant ວ່າມີການເຮັດທຸລະກໍາຢູ່ໃນສໍາລອງທີ່ບໍ່ໄດ້ຢູ່ໃນແມ່ບົດ. ເປັນຫຍັງເລື່ອງນີ້ເກີດຂຶ້ນ?

• Read_only=1 ບໍ່​ໄດ້​ເປີດ​ໃຊ້​ງານ​ຢູ່​ໃນ slave, ມີ​ຄົນ​ເຊື່ອມ​ຕໍ່​ແລະ​ເຮັດ​ສຳ​ເລັດ​ການ​ຮ້ອງ​ຂໍ​ໃຫ້​ປ່ຽນ​ຂໍ້​ມູນ.
• Super_read_only=1 ບໍ່ໄດ້ເປີດໃຊ້ໃນ slave, ຫຼັງຈາກນັ້ນ, ຜູ້ເບິ່ງແຍງລະບົບ, ສັບສົນກັບເຄື່ອງແມ່ຂ່າຍ, ເຂົ້າໄປໃນແລະປະຕິບັດການຮ້ອງຂໍຢູ່ທີ່ນັ້ນ.
• ຖ້າທ່ານພິຈາລະນາທັງສອງຈຸດທີ່ຜ່ານມາ, ຫຼັງຈາກນັ້ນ, ມີອີກຫນຶ່ງ trick: ໃນ MySQL, ການຮ້ອງຂໍໃຫ້ flush binlogs ຍັງໄປຫາ binlog, ດັ່ງນັ້ນໃນຕອນທໍາອິດ, ຄວາມຜິດພາດ GTID ຈະປາກົດຢູ່ໃນແມ່ບົດແລະສໍາລອງທັງຫມົດ. ວິທີການຫຼີກເວັ້ນການນີ້? Perona-5.7.25-28 ແນະນຳການຕັ້ງຄ່າ binlog_skip_flush_commands=1, ເຊິ່ງຫ້າມຂຽນ flush ໃສ່ binlogs. ມີການສ້າງຕັ້ງຂຶ້ນຢູ່ໃນເວັບໄຊທ໌ mysql.com ແມງໄມ້.

ຂ້າພະເຈົ້າຂໍສະຫຼຸບທັງຫມົດຂ້າງເທິງ. ຖ້າທ່ານບໍ່ຕ້ອງການໃຊ້ Orchestrator ໃນໂຫມດລົ້ມເຫລວເທື່ອ, ຫຼັງຈາກນັ້ນໃຫ້ໃສ່ໃນໂຫມດສັງເກດ. ຫຼັງຈາກນັ້ນ, ເຈົ້າຈະມີແຜນທີ່ຂອງປະຕິສໍາພັນຂອງເຄື່ອງຈັກ MySQL ແລະຂໍ້ມູນສາຍຕາກ່ຽວກັບສິ່ງທີ່ປະເພດຂອງການຈໍາລອງຢູ່ໃນແຕ່ລະເຄື່ອງຈັກ, ບໍ່ວ່າຈະເປັນຂ້າທາດທີ່ລ້າສະໄຫມ, ແລະສໍາຄັນທີ່ສຸດ, ມີຄວາມສອດຄ່ອງແນວໃດກັບແມ່ບົດ!

ຄໍາຖາມທີ່ຊັດເຈນແມ່ນ: "ນັກ Orchestrator ຄວນເຮັດວຽກແນວໃດ?" ລາວຕ້ອງເລືອກນາຍໃຫມ່ຈາກຂ້າທາດໃນປະຈຸບັນ, ແລະຫຼັງຈາກນັ້ນເຊື່ອມຕໍ່ສໍາລອງທັງຫມົດກັບມັນ (ນີ້ແມ່ນສິ່ງທີ່ GTID ຕ້ອງການ; ຖ້າທ່ານໃຊ້ກົນໄກເກົ່າກັບ binlog_name ແລະ binlog_pos, ຫຼັງຈາກນັ້ນປ່ຽນສໍາລອງຈາກແມ່ບົດປະຈຸບັນໄປສູ່ໃຫມ່. ມັນເປັນໄປບໍ່ໄດ້!). ກ່ອນ​ທີ່​ພວກ​ເຮົາ​ຈະ​ມີ Orchestrator, ຄັ້ງ​ຫນຶ່ງ​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເຮັດ​ທັງ​ຫມົດ​ນີ້​ດ້ວຍ​ຕົນ​ເອງ. ແມ່ບົດເກົ່າຖືກຫ້ອຍເນື່ອງຈາກຕົວຄວບຄຸມ Adaptec buggy ມັນມີຂ້າທາດປະມານ 10 ຄົນ. ຂ້າ​ພະ​ເຈົ້າ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ໂອນ VIP ຈາກ​ນາຍ​ກັບ​ຫນຶ່ງ​ຂອງ​ສໍາ​ລອງ​ແລະ reconnect ສໍາ​ລອງ​ອື່ນໆ​ທັງ​ຫມົດ​ກັບ​ມັນ​. ຂ້ອຍຕ້ອງເປີດຈັກເຄື່ອງ, ຈັກເຄື່ອງພ້ອມໆກັນເຂົ້າ... ຂ້ອຍຕ້ອງລໍຖ້າຮອດ 3 ໂມງເຊົ້າ, ເອົາເຄື່ອງຂອງອອກຈາກທາດທັງໝົດ ຍົກເວັ້ນສອງເຄື່ອງ, ເຮັດເຄື່ອງທຳອິດຂອງສອງນາຍ, ຕິດເຄື່ອງທີສອງທັນທີ. ກັບມັນ, ດັ່ງນັ້ນ, ຄັດຕິດສໍາລອງອື່ນໆທັງຫມົດກັບນາຍໃຫມ່ແລະສົ່ງຄືນ. ໂດຍລວມ, ຂີ້ຮ້າຍ ...

Orchestrator ເຮັດວຽກແນວໃດເມື່ອມັນເຂົ້າສູ່ໂໝດລົ້ມເຫລວ? ນີ້ແມ່ນສະແດງໃຫ້ເຫັນໄດ້ງ່າຍທີ່ສຸດໂດຍຕົວຢ່າງຂອງສະຖານະການທີ່ພວກເຮົາຕ້ອງການທີ່ຈະເຮັດໃຫ້ແມ່ບົດມີຄວາມເຂັ້ມແຂງ, ເຄື່ອງຈັກທີ່ທັນສະໄຫມຫຼາຍກ່ວາໃນປັດຈຸບັນ.

ຕົວເລກສະແດງໃຫ້ເຫັນເຖິງກາງຂອງຂະບວນການ. ມາຮອດຈຸດນີ້ແມ່ນຫຍັງ? ພວກ​ເຮົາ​ໄດ້​ເວົ້າ​ວ່າ​ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ເຮັດ​ໃຫ້​ສໍາ​ລອງ​ບາງ​ນາຍ​ໃຫມ່​, Orchestrator ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ເຊື່ອມ​ຕໍ່​ກັບ​ຂ້າ​ໃຊ້​ອື່ນໆ​ທັງ​ຫມົດ​ກັບ​ມັນ​, ກັບ​ນາຍ​ໃຫມ່​ເຮັດ​ຫນ້າ​ທີ່​ເປັນ​ເຄື່ອງ​ຂົນ​ສົ່ງ​. ດ້ວຍໂຄງການນີ້, ບໍ່ມີຂໍ້ຜິດພາດເກີດຂື້ນ, ຂ້າທາດທັງຫມົດເຮັດວຽກ, Orchestrator ເອົາ VIP ອອກຈາກຕົ້ນສະບັບເກົ່າ, ໂອນໄປໃຫມ່, ເຮັດໃຫ້ read_only=0 ແລະລືມກ່ຽວກັບຕົ້ນສະບັບເກົ່າ. ທັງໝົດ! ການຢຸດເຊົາການບໍລິການຂອງພວກເຮົາແມ່ນເວລາການໂອນ VIP, ເຊິ່ງແມ່ນ 2-3 ວິນາທີ.

ນັ້ນແມ່ນທັງຫມົດສໍາລັບມື້ນີ້, ຂອບໃຈທຸກຄົນ. ຈະມີບົດຄວາມທີສອງກ່ຽວກັບ Orchestrator ໃນໄວໆນີ້. ໃນຮູບເງົາໂຊວຽດທີ່ມີຊື່ສຽງ "Garage," ຕົວລະຄອນຫນຶ່ງເວົ້າວ່າ, "ຂ້ອຍຈະບໍ່ໄປສອດແນມກັບລາວ!" ດັ່ງນັ້ນ, Orchestrator, ຂ້ອຍຈະໄປກັບເຈົ້າໃນການສອດແນມ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com