ທີ່ Citymobil ພວກເຮົາໃຊ້ຖານຂໍ້ມູນ MySQL ເປັນການເກັບຮັກສາຂໍ້ມູນຕົ້ນຕໍຂອງພວກເຮົາຢ່າງຕໍ່ເນື່ອງ. ພວກເຮົາມີກຸ່ມຖານຂໍ້ມູນຈໍານວນຫນຶ່ງສໍາລັບການບໍລິການແລະຈຸດປະສົງຕ່າງໆ.

ການມີຢູ່ຄົງທີ່ຂອງແມ່ບົດແມ່ນຕົວຊີ້ວັດທີ່ສໍາຄັນຂອງການປະຕິບັດຂອງລະບົບທັງຫມົດແລະພາກສ່ວນສ່ວນບຸກຄົນຂອງມັນ. ການຟື້ນຟູກຸ່ມອັດຕະໂນມັດໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງແມ່ບົດຫຼຸດລົງຢ່າງຫຼວງຫຼາຍເວລາຕອບສະຫນອງເຫດການແລະການຢຸດລະບົບ. ໃນບົດຄວາມນີ້, ຂ້ອຍຈະເບິ່ງການອອກແບບທີ່ມີຄວາມພ້ອມສູງ (HA) ສໍາລັບກຸ່ມ MySQL ໂດຍອີງໃສ່ MySQL Orchestrator ແລະທີ່ຢູ່ IP virtual (VIP).

ການແກ້ໄຂ HA ໂດຍອີງໃສ່ VIP

ກ່ອນອື່ນ, ຂ້ອຍຈະບອກເຈົ້າສັ້ນໆວ່າລະບົບການເກັບຮັກສາຂໍ້ມູນຂອງພວກເຮົາແມ່ນຫຍັງ.

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

Replication ແມ່ນດໍາເນີນຢູ່ໃນຮູບແບບເຄິ່ງ synchronous ໂດຍອີງໃສ່ GTID. ນີ້ຫມາຍຄວາມວ່າຢ່າງຫນ້ອຍຫນຶ່ງ replica ຕ້ອງບັນທຶກການເຮັດທຸລະກໍາກ່ອນທີ່ມັນຈະຖືວ່າປະສົບຜົນສໍາເລັດ. ຮູບແບບການຈໍາລອງນີ້ສະຫນອງຄວາມສົມດຸນທີ່ດີທີ່ສຸດລະຫວ່າງການປະຕິບັດແລະຄວາມປອດໄພຂອງຂໍ້ມູນໃນກໍລະນີທີ່ມີຂໍ້ບົກຜ່ອງຕົ້ນສະບັບ. ໂດຍພື້ນຖານແລ້ວການປ່ຽນແປງທັງຫມົດແມ່ນໄດ້ຖືກໂອນຈາກຕົ້ນສະບັບໄປຫາ replicas ໂດຍໃຊ້ Row Based Replication (RBR), ແຕ່ບາງ nodes ອາດຈະມີ mixed binlog format.

orchestrator ເປັນໄລຍະປັບປຸງສະຖານະຂອງ topology ກຸ່ມ, ວິເຄາະຂໍ້ມູນທີ່ໄດ້ຮັບ, ແລະຖ້າຫາກວ່າບັນຫາເກີດຂຶ້ນ, ມັນສາມາດເປີດຕົວຂັ້ນຕອນການຟື້ນຕົວອັດຕະໂນມັດ. ນັກພັດທະນາມີຄວາມຮັບຜິດຊອບຕໍ່ຂັ້ນຕອນຂອງຕົວມັນເອງ, ເພາະວ່າມັນສາມາດຖືກປະຕິບັດໃນວິທີຕ່າງໆ: ອີງໃສ່ VIP, DNS, ການນໍາໃຊ້ການບໍລິການຄົ້ນພົບການບໍລິການຫຼືກົນໄກທີ່ຂຽນດ້ວຍຕົນເອງ.

ວິທີງ່າຍໆອັນໜຶ່ງທີ່ຈະຟື້ນຟູແມ່ແບບ ຖ້າມັນລົ້ມເຫລວແມ່ນການໃຊ້ທີ່ຢູ່ VIP ແບບລອຍຕົວ.

ສິ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບການແກ້ໄຂນີ້ກ່ອນທີ່ຈະກ້າວໄປຂ້າງຫນ້າ:

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

ຂໍໃຫ້ເບິ່ງບັນຫາທີ່ເປັນໄປໄດ້ກັບຕົວຊ່ວຍສ້າງຂອງພວກເຮົາແລະຈິນຕະນາການວ່າກົນໄກການຟື້ນຕົວອັດຕະໂນມັດຄວນເຮັດວຽກແນວໃດ.

ການ​ເຊື່ອມ​ຕໍ່​ເຄືອ​ຂ່າຍ​ກັບ​ຕົ້ນ​ສະ​ບັບ​ໄດ້​ຫາຍ​ໄປ​, ຫຼື​ບັນ​ຫາ​ໄດ້​ເກີດ​ຂຶ້ນ​ໃນ​ລະ​ດັບ​ຮາດ​ແວ​, ແລະ​ເຊີບ​ເວີ​ບໍ່​ສາ​ມາດ​ໃຊ້​ໄດ້

1. Orchestrator ປັບປຸງ topology ຂອງກຸ່ມ, ແຕ່ລະ replica ລາຍງານວ່າແມ່ແບບບໍ່ສາມາດໃຊ້ໄດ້. orchestrator ເລີ່ມຕົ້ນຂະບວນການຂອງການຄັດເລືອກ replica ທີ່ເຫມາະສົມສໍາລັບພາລະບົດບາດຂອງຕົ້ນສະບັບໃຫມ່ແລະເລີ່ມຕົ້ນການຟື້ນຕົວ.
2. ພວກເຮົາກໍາລັງພະຍາຍາມເອົາ VIP ອອກຈາກຕົ້ນສະບັບເກົ່າ - ໂດຍບໍ່ມີຜົນສໍາເລັດ.
3. ການຈໍາລອງປ່ຽນໄປສູ່ບົດບາດຂອງແມ່ບົດ. topology ກໍາລັງຖືກສ້າງໃຫມ່.
4. ເພີ່ມການໂຕ້ຕອບເຄືອຂ່າຍໃຫມ່ກັບ VIP. ເນື່ອງຈາກມັນບໍ່ສາມາດເອົາ VIP ອອກໄດ້, ພວກເຮົາເລີ່ມສົ່ງຄໍາຮ້ອງຂໍເປັນໄລຍະໆໃນພື້ນຫຼັງ ARP ຟຣີ. ປະເພດຂອງການຮ້ອງຂໍ / ຄໍາຕອບນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດປັບປຸງຕາຕະລາງແຜນທີ່ທີ່ຢູ່ IP ແລະ MAC ໃນສະວິດທີ່ເຊື່ອມຕໍ່, ດັ່ງນັ້ນຈຶ່ງແຈ້ງໃຫ້ທ່ານຮູ້ວ່າ VIP ຂອງພວກເຮົາໄດ້ຍ້າຍ. ນີ້ຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ split brain ​ເມື່ອ​ກັບ​ຄືນ​ນາຍ​ເກົ່າ.
5. ການເຊື່ອມຕໍ່ໃຫມ່ທັງຫມົດຈະຖືກໂອນໄປຫາແມ່ແບບໃຫມ່ທັນທີ. ການເຊື່ອມຕໍ່ເກົ່າລົ້ມເຫລວແລະການໂທຊ້ໍາກັບຖານຂໍ້ມູນແມ່ນເຮັດຢູ່ໃນລະດັບຄໍາຮ້ອງສະຫມັກ.

ເຊີບເວີກຳລັງເຮັດວຽກຢູ່ໃນໂໝດປົກກະຕິ, ຄວາມລົ້ມເຫຼວເກີດຂຶ້ນໃນລະດັບ DBMS

ສູດການຄິດໄລ່ແມ່ນຄ້າຍຄືກັນກັບກໍລະນີທີ່ຜ່ານມາ: ການປັບປຸງ topology ແລະເລີ່ມຕົ້ນຂະບວນການຟື້ນຟູ. ນັບຕັ້ງແຕ່ເຄື່ອງແມ່ຂ່າຍສາມາດໃຊ້ໄດ້, ພວກເຮົາສົບຜົນສໍາເລັດປ່ອຍ VIP ໃນຕົ້ນສະບັບເກົ່າ, ໂອນມັນໄປຫາໃຫມ່, ແລະສົ່ງຄໍາຮ້ອງຂໍ ARP ຫຼາຍ. ການກັບຄືນທີ່ເປັນໄປໄດ້ຂອງຕົ້ນສະບັບເກົ່າບໍ່ຄວນສົ່ງຜົນກະທົບຕໍ່ກຸ່ມທີ່ສ້າງຂຶ້ນໃຫມ່ແລະການດໍາເນີນງານຂອງແອັບພລິເຄຊັນ.

ປັນຫາອື່ນໆ

ຄວາມລົ້ມເຫຼວຂອງ replicas ຫຼືແມ່ບົດລະດັບກາງ ບໍ່ໄດ້ນໍາພາ ເພື່ອປະຕິບັດອັດຕະໂນມັດແລະຮຽກຮ້ອງໃຫ້ມີການແຊກແຊງຄູ່ມື.

ການໂຕ້ຕອບເຄືອຂ່າຍ virtual ສະເຫມີຖືກເພີ່ມຊົ່ວຄາວ, ນັ້ນແມ່ນ, ຫຼັງຈາກເຄື່ອງແມ່ຂ່າຍໃຫມ່, VIP ບໍ່ໄດ້ຖືກມອບຫມາຍໂດຍອັດຕະໂນມັດ. ແຕ່ລະຕົວຢ່າງຖານຂໍ້ມູນເລີ່ມຕົ້ນໃນໂຫມດອ່ານເທົ່ານັ້ນຕາມຄ່າເລີ່ມຕົ້ນ, ຜູ້ orchestrator ຈະປ່ຽນຕົ້ນສະບັບໃຫມ່ໂດຍອັດຕະໂນມັດເພື່ອຂຽນແລະພະຍາຍາມຕິດຕັ້ງ. read only ກ່ຽວກັບນາຍເກົ່າ. ການ​ກະທຳ​ເຫຼົ່າ​ນີ້​ແມ່ນ​ແນ​ໃສ່​ຫຼຸດຜ່ອນ​ຄວາມ​ເປັນ​ໄປ​ໄດ້ split brain.

ບັນຫາອາດຈະເກີດຂື້ນໃນລະຫວ່າງຂະບວນການຟື້ນຟູ, ເຊິ່ງຄວນແຈ້ງໃຫ້ຮູ້ໂດຍຜ່ານ orchestrator UI ນອກເຫນືອຈາກເຄື່ອງມືຕິດຕາມມາດຕະຖານ. ພວກເຮົາໄດ້ຂະຫຍາຍ REST API ໂດຍການເພີ່ມຄຸນສົມບັດນີ້ (PR ປະຈຸບັນຢູ່ໃນການກວດສອບ).

ແຜນວາດທົ່ວໄປຂອງການແກ້ໄຂ HA ໄດ້ຖືກນໍາສະເຫນີຂ້າງລຸ່ມນີ້.

ການເລືອກແມ່ບົດໃຫມ່

orchestrator ແມ່ນ smart ພຽງ​ພໍ​ແລະ​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ເລືອກ​ເອົາ replica ທີ່ເຫມາະສົມທີ່ສຸດ ເປັນແມ່ບົດໃໝ່ຕາມເງື່ອນໄຂດັ່ງນີ້:

• replica ໄດ້ lags ທາງຫລັງຂອງຕົ້ນສະບັບ;
• ສະບັບ MySQL ຂອງຕົ້ນສະບັບແລະ replica;
• ປະເພດ replication (RBR, SBR ຫຼືປະສົມ);
• ສະຖານທີ່ຢູ່ໃນສູນຂໍ້ມູນດຽວກັນຫຼືທີ່ແຕກຕ່າງກັນ;
• ມີຄວາມພ້ອມ errant GTID - ການເຮັດທຸລະກໍາທີ່ຖືກປະຕິບັດຢູ່ໃນ replica ແລະບໍ່ໄດ້ຢູ່ໃນຕົ້ນສະບັບ;
• ກົດລະບຽບການຄັດເລືອກທີ່ກໍາຫນົດເອງຍັງຖືກພິຈາລະນາ.

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

ການຕອບສະ ໜອງ ແລະເວລາການຟື້ນຕົວ

ໃນກໍລະນີຂອງເຫດການ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຫຼຸດຜ່ອນການຢຸດຂອງລະບົບ, ສະນັ້ນໃຫ້ພິຈາລະນາຕົວກໍານົດການ MySQL ທີ່ມີຜົນກະທົບຕໍ່ການສ້າງແລະປັບປຸງ topology ຂອງກຸ່ມໂດຍ orchestrator:

• slave_net_timeout — ຈໍາ​ນວນ​ວິ​ນາ​ທີ​ໃນ​ໄລ​ຍະ​ທີ່ replica ໄດ້​ລໍ​ຖ້າ​ສໍາ​ລັບ​ຂໍ້​ມູນ​ໃຫມ່​ຫຼື​ສັນ​ຍານ​ການ​ເຕັ້ນ​ຂອງ​ຫົວ​ໃຈ​ມາ​ຈາກ​ແມ່​ບົດ​ກ່ອນ​ທີ່​ການ​ເຊື່ອມ​ຕໍ່​ຈະ​ຖືກ​ຮັບ​ຮູ້​ວ່າ​ສູນ​ເສຍ​ແລະ​ເຊື່ອມ​ຕໍ່​ຄືນ​ໃຫມ່​. ມູນຄ່າຕ່ໍາ, ການຈໍາລອງໄວຂຶ້ນສາມາດກໍານົດວ່າການສື່ສານກັບແມ່ບົດຖືກທໍາລາຍ. ພວກເຮົາກໍານົດຄ່ານີ້ເປັນ 5 ວິນາທີ.
• MASTER_CONNECT_RETRY — ຈໍານວນວິນາທີລະຫວ່າງຄວາມພະຍາຍາມເຊື່ອມຕໍ່ຄືນໃໝ່. ໃນກໍລະນີທີ່ມີບັນຫາເຄືອຂ່າຍ, ມູນຄ່າຕໍ່າສໍາລັບພາລາມິເຕີນີ້ຈະຊ່ວຍໃຫ້ການເຊື່ອມຕໍ່ຄືນໃຫມ່ໄວແລະປ້ອງກັນບໍ່ໃຫ້ຂະບວນການຟື້ນຕົວຂອງກຸ່ມເລີ່ມຕົ້ນ. ຄ່າທີ່ແນະນຳແມ່ນ 1 ວິນາທີ.
• MASTER_RETRY_COUNT - ຈໍານວນສູງສຸດຂອງຄວາມພະຍາຍາມເຊື່ອມຕໍ່ໃຫມ່.
• MASTER_HEARTBEAT_PERIOD — ໄລ​ຍະ​ຫ່າງ​ໃນ​ວິ​ນາ​ທີ​ຫຼັງ​ຈາກ​ນັ້ນ​ແມ່​ບົດ​ສົ່ງ​ສັນ​ຍານ​ການ​ເຕັ້ນ​ຂອງ​ຫົວ​ໃຈ​. ຄ່າເລີ່ມຕົ້ນເປັນເຄິ່ງຫນຶ່ງຂອງມູນຄ່າ slave_net_timeout.

ຕົວກໍານົດການ Orchestrator:

• DelayMasterPromotionIfSQLThreadNotUpToDate - ຖ້າ​ເທົ່າ​ທຽມ​ກັນ​ true, ຫຼັງຈາກນັ້ນ, ບົດບາດຕົ້ນສະບັບຈະບໍ່ຖືກນໍາໄປໃຊ້ກັບຕົວແບບຜູ້ສະຫມັກຈົນກ່ວາຫົວຂໍ້ SQL ຂອງ replica ໄດ້ສໍາເລັດການເຮັດທຸລະກໍາທີ່ບໍ່ໄດ້ນໍາໃຊ້ທັງຫມົດຈາກ Relay Log. ພວກເຮົາໃຊ້ທາງເລືອກນີ້ເພື່ອຫຼີກເວັ້ນການສູນເສຍການເຮັດທຸລະກໍາເມື່ອຜູ້ສະຫມັກທັງຫມົດຕົກຢູ່ຫລັງ.
• InstancePollSeconds — ຄວາມ​ຖີ່​ຂອງ​ການ​ກໍ່​ສ້າງ​ແລະ​ການ​ປັບ​ປຸງ topology​.
• RecoveryPollSeconds - ຄວາມ​ຖີ່​ຂອງ​ການ​ວິ​ເຄາະ topology​. ຖ້າພົບບັນຫາ, ການຟື້ນຕົວ topology ແມ່ນເລີ່ມຕົ້ນ. ນີ້ ຄົງທີ່, ເທົ່າກັບ 1 ວິນາທີ.

ແຕ່ລະ node ຂອງກຸ່ມຖືກສຳຫຼວດໂດຍນັກປະພັນທຸກຄັ້ງ InstancePollSeconds ວິນາທີ ເມື່ອກວດພົບບັນຫາ, ສະຖານະຂອງກຸ່ມຖືກບັງຄັບ ອັບເດດ, ແລະຫຼັງຈາກນັ້ນການຕັດສິນໃຈສຸດທ້າຍແມ່ນເຮັດເພື່ອປະຕິບັດການຟື້ນຕົວ. ໂດຍການທົດລອງກັບຖານຂໍ້ມູນແລະຕົວກໍານົດການ orchestrator ທີ່ແຕກຕ່າງກັນ, ພວກເຮົາສາມາດຫຼຸດຜ່ອນເວລາຕອບສະຫນອງແລະການຟື້ນຕົວເປັນ 30 ວິນາທີ.

ຢືນທົດສອບ

ພວກເຮົາໄດ້ເລີ່ມທົດສອບໂຄງການ HA ກັບການພັດທະນາທ້ອງຖິ່ນ ບ່ອນນັ່ງທົດສອບ ແລະການປະຕິບັດຕໍ່ໄປໃນສະພາບແວດລ້ອມການທົດສອບແລະການຜະລິດ. ຈຸດຢືນໃນທ້ອງຖິ່ນແມ່ນອັດຕະໂນມັດຢ່າງເຕັມສ່ວນໂດຍອີງໃສ່ Docker ແລະອະນຸຍາດໃຫ້ທ່ານສາມາດທົດລອງກັບການຕັ້ງຄ່າຂອງ orchestrator ແລະເຄືອຂ່າຍ, ຂະຫນາດກຸ່ມຈາກ 2-3 ເຊີຟເວີໄປຫາຫຼາຍອາຍແກັສ, ແລະດໍາເນີນການອອກກໍາລັງກາຍໃນສະພາບແວດລ້ອມທີ່ປອດໄພ.

ໃນ​ລະ​ຫວ່າງ​ການ​ອອກ​ກໍາ​ລັງ​ກາຍ​, ພວກ​ເຮົາ​ເລືອກ​ເອົາ​ຫນຶ່ງ​ໃນ​ວິ​ທີ​ການ​ຈໍາ​ລອງ​ບັນ​ຫາ​: ທັນ​ທີ​ທັນ​ໃດ​ຍິງ​ແມ່​ບົດ​ໂດຍ​ນໍາ​ໃຊ້​ kill -9, ຄ່ອຍໆຢຸດຂະບວນການແລະຢຸດເຄື່ອງແມ່ຂ່າຍ (docker-compose stop), simulate ບັນຫາເຄືອຂ່າຍໂດຍໃຊ້ iptables -j REJECT ຫຼື iptables -j DROP. ພວກເຮົາຄາດຫວັງວ່າຜົນໄດ້ຮັບຕໍ່ໄປນີ້:

• orchestrator ຈະກວດພົບບັນຫາກັບແມ່ບົດແລະປັບປຸງ topology ໃນເວລາບໍ່ເກີນ 10 ວິນາທີ;
• ຂັ້ນຕອນການຟື້ນຕົວຈະເລີ່ມຕົ້ນໂດຍອັດຕະໂນມັດ: ການຕັ້ງຄ່າເຄືອຂ່າຍຈະປ່ຽນແປງ, ບົດບາດຂອງແມ່ບົດຈະຜ່ານໄປ replica, topology ຈະຖືກສ້າງໃຫມ່;
• ຕົ້ນສະບັບໃຫມ່ຈະກາຍເປັນຂຽນໄດ້, replicas ດໍາລົງຊີວິດຈະບໍ່ສູນເສຍໄປໃນລະຫວ່າງຂະບວນການສ້າງໃຫມ່;
• ຂໍ້​ມູນ​ຈະ​ເລີ່ມ​ຕົ້ນ​ທີ່​ຈະ​ຖືກ​ລາຍ​ລັກ​ອັກ​ສອນ​ໃຫມ່​ແລະ replicated​;
• ເວລາການຟື້ນຕົວທັງໝົດຈະບໍ່ເກີນ 30 ວິນາທີ.

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

ການຄົ້ນພົບ

ສຸຂະພາບຂອງລະບົບການເກັບຮັກສາຕົ້ນຕໍແມ່ນຫນຶ່ງໃນວຽກງານຕົ້ນຕໍຂອງ SRE ແລະທີມງານປະຕິບັດງານ. ການປະຕິບັດຂອງ orchestrator ແລະການແກ້ໄຂ HA ໂດຍອີງໃສ່ VIP ໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາບັນລຸຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

• ການກວດສອບທີ່ເຊື່ອຖືໄດ້ຂອງບັນຫາກັບ topology ຂອງກຸ່ມຖານຂໍ້ມູນ;
• ການຕອບສະ ໜອງ ອັດຕະໂນມັດແລະໄວຕໍ່ເຫດການທີ່ກ່ຽວຂ້ອງກັບແມ່ບົດ, ຫຼຸດຜ່ອນການຢຸດລະບົບ.

ຢ່າງໃດກໍຕາມ, ການແກ້ໄຂມີຂໍ້ຈໍາກັດແລະຂໍ້ເສຍຂອງມັນ:

• ການຂະຫຍາຍໂຄງການ HA ໄປຫາສູນຂໍ້ມູນຫຼາຍແຫ່ງຈະຕ້ອງມີເຄືອຂ່າຍ L2 ດຽວລະຫວ່າງພວກມັນ;
• ກ່ອນທີ່ຈະມອບຫມາຍ VIP ໃນແມ່ບົດໃຫມ່, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ອຍມັນຢູ່ໃນອັນເກົ່າ. ຂະບວນການແມ່ນຕາມລໍາດັບ, ເຊິ່ງເພີ່ມເວລາການຟື້ນຕົວ;
• ການປ່ອຍ VIP ຮຽກຮ້ອງໃຫ້ມີການເຂົ້າເຖິງ SSH ກັບເຄື່ອງແມ່ຂ່າຍ, ຫຼືວິທີການອື່ນໆຂອງການໂທຫາຂັ້ນຕອນທາງໄກ. ເນື່ອງຈາກເຄື່ອງແມ່ຂ່າຍຫຼືຖານຂໍ້ມູນກໍາລັງປະສົບບັນຫາທີ່ເຮັດໃຫ້ເກີດຂະບວນການຟື້ນຕົວ, ພວກເຮົາບໍ່ສາມາດແນ່ໃຈວ່າການໂຍກຍ້າຍ VIP ຈະສໍາເລັດສົບຜົນສໍາເລັດ. ແລະນີ້ສາມາດນໍາໄປສູ່ຮູບລັກສະນະຂອງສອງເຄື່ອງແມ່ຂ່າຍທີ່ມີທີ່ຢູ່ IP virtual ດຽວກັນແລະມີບັນຫາ split brain.

ເພື່ອຫຼີກເວັ້ນການ split brain, ທ່ານສາມາດນໍາໃຊ້ວິທີການ STONITH (“Shoot the other node in the Head”), ເຊິ່ງເຮັດໃຫ້ໂດດດ່ຽວ ຫຼືປິດການໃຊ້ງານ node ບັນຫາ. ມີວິທີອື່ນເພື່ອປະຕິບັດການມີກຸ່ມທີ່ມີຄວາມພ້ອມສູງ: ການປະສົມປະສານຂອງ VIP ແລະ DNS, ການຄົ້ນພົບການບໍລິການແລະການບໍລິການຕົວແທນ, ການຈໍາລອງແບບ synchronous ແລະວິທີການອື່ນໆທີ່ມີຂໍ້ເສຍແລະຂໍ້ດີຂອງຕົນເອງ.

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

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