ການນໍາສະເຫນີ

ບາງຄັ້ງກ່ອນຫນ້ານີ້ຂ້າພະເຈົ້າໄດ້ຮັບຫນ້າທີ່ຂອງການພັດທະນາ cluster failover ສໍາລັບ PostgreSQL, ປະຕິບັດງານຢູ່ໃນສູນຂໍ້ມູນຈໍານວນຫນຶ່ງທີ່ເຊື່ອມຕໍ່ດ້ວຍເສັ້ນໄຍ optical ພາຍໃນເມືອງຫນຶ່ງ, ແລະສາມາດທົນກັບຄວາມລົ້ມເຫຼວ (ຕົວຢ່າງເຊັ່ນ, ການປິດ) ຂອງສູນຂໍ້ມູນຫນຶ່ງ. ໃນຖານະເປັນຊອບແວທີ່ຮັບຜິດຊອບສໍາລັບຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ, ຂ້າພະເຈົ້າໄດ້ເລືອກ ມ້ານໍາເນື່ອງຈາກວ່ານີ້ແມ່ນການແກ້ໄຂຢ່າງເປັນທາງການຈາກ RedHat ສໍາລັບການສ້າງ clusters ລົ້ມເຫລວ. ມັນເປັນສິ່ງທີ່ດີເພາະວ່າ RedHat ສະຫນອງການສະຫນັບສະຫນູນສໍາລັບມັນ, ແລະເນື່ອງຈາກວ່າການແກ້ໄຂນີ້ແມ່ນທົ່ວໄປ (modular). ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ມັນຈະເປັນໄປໄດ້ທີ່ຈະຮັບປະກັນຄວາມທົນທານຕໍ່ຄວາມຜິດບໍ່ພຽງແຕ່ຂອງ PostgreSQL, ແຕ່ຍັງການບໍລິການອື່ນໆ, ບໍ່ວ່າຈະເປັນການນໍາໃຊ້ໂມດູນມາດຕະຖານຫຼືສ້າງໃຫ້ເຂົາເຈົ້າສໍາລັບຄວາມຕ້ອງການສະເພາະ.

ການ​ຕັດສິນ​ໃຈ​ນີ້​ໄດ້​ສ້າງ​ຄຳ​ຖາມ​ທີ່​ສົມ​ເຫດ​ສົມ​ຜົນ​ຄື: ກຸ່ມ​ຄວາມ​ລົ້ມ​ເຫຼວ​ຈະ​ເປັນ​ແນວ​ໃດ? ເພື່ອສືບສວນນີ້, ຂ້າພະເຈົ້າໄດ້ພັດທະນາການທົດສອບ bench ທີ່ຈໍາລອງຄວາມລົ້ມເຫລວຕ່າງໆໃນ nodes cluster, ລໍຖ້າການບໍລິການທີ່ຈະຟື້ນຟູ, ຟື້ນຟູ node ທີ່ລົ້ມເຫລວ, ແລະສືບຕໍ່ການທົດສອບໃນ loop. ໂຄງ​ການ​ນີ້​ໃນ​ເບື້ອງ​ຕົ້ນ​ເອີ້ນ​ວ່າ hapgsql​, ແຕ່​ວ່າ​ໃນ​ໄລ​ຍະ​ເວ​ລາ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ເບື່ອ​ກັບ​ຊື່​, ທີ່​ມີ​ພຽງ​ແຕ່​ສະ​ຫນຸກ​ສະ​ນະ​ຫນຶ່ງ​. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ເລີ່ມໂທຫາຖານຂໍ້ມູນທີ່ທົນທານຕໍ່ຄວາມຜິດ (ແລະ float IP ຊີ້ໄປຫາພວກເຂົາ) ກຸ້ງ (ຕົວລະຄອນຈາກເກມຄອມພິວເຕີທີ່ອະໄວຍະວະທີ່ສຳຄັນທັງໝົດຖືກຊໍ້າກັນ), ແລະ nodes, clusters ແລະ project ຕົວຂອງມັນເອງແມ່ນ. tuchanka (ດາວເຄາະທີ່ krogans ອາໄສຢູ່).

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

ກຸ່ມຖືກນຳໃຊ້ຢູ່ໃນເຄື່ອງສະເໝືອນ VirtualBox. ຈໍານວນເຄື່ອງ virtual ທັງຫມົດ 12 ເຄື່ອງ (ຈໍານວນທັງຫມົດ 36GiB) ຈະຖືກນໍາໄປໃຊ້, ເຊິ່ງປະກອບເປັນ 4 ກຸ່ມທີ່ທົນທານຕໍ່ຄວາມຜິດ (ທາງເລືອກທີ່ແຕກຕ່າງກັນ). ສອງກຸ່ມທໍາອິດປະກອບດ້ວຍສອງເຄື່ອງແມ່ຂ່າຍ PostgreSQL, ເຊິ່ງຕັ້ງຢູ່ໃນສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນ, ແລະເຄື່ອງແມ່ຂ່າຍທົ່ວໄປ. ພະຍານ c ອຸປະກອນກຸ່ມ (ໂຮດຢູ່ໃນເຄື່ອງ virtual ລາຄາຖືກໃນສູນຂໍ້ມູນທີສາມ), ເຊິ່ງແກ້ໄຂຄວາມບໍ່ແນ່ນອນ 50% / 50%, ໃຫ້ຄະແນນສຽງຂອງທ່ານກັບຫນຶ່ງໃນພາກສ່ວນ. ກຸ່ມທີສາມໃນສາມສູນຂໍ້ມູນ: ຫນຶ່ງຕົ້ນສະບັບ, ສອງສໍາລອງ, ບໍ່ມີ ອຸປະກອນກຸ່ມ. ກຸ່ມທີ່ສີ່ປະກອບດ້ວຍສີ່ເຄື່ອງແມ່ຂ່າຍ PostgreSQL, ສອງຕໍ່ສູນຂໍ້ມູນ: ຫນຶ່ງຕົ້ນສະບັບ, replicas ສ່ວນທີ່ເຫຼືອ, ແລະຍັງໃຊ້. ພະຍານ c ອຸປະກອນກຸ່ມ. ສີ່ສາມາດທົນກັບຄວາມລົ້ມເຫຼວຂອງສອງເຄື່ອງແມ່ຂ່າຍຫຼືສູນຂໍ້ມູນຫນຶ່ງ. ການແກ້ໄຂນີ້ສາມາດຖືກປັບຂະຫນາດເປັນຈໍານວນຂະຫນາດໃຫຍ່ຂອງ replicas ຖ້າຈໍາເປັນ.

ບໍລິການເວລາທີ່ຖືກຕ້ອງ ntpd ຍັງ configured ສໍາລັບຄວາມທົນທານຄວາມຜິດ, ແຕ່ມັນໃຊ້ວິທີການຕົວມັນເອງ ntpd (ໂໝດເດັກກຳພ້າ). ເຊີບເວີທີ່ແບ່ງປັນ ພະຍານ ເຮັດໜ້າທີ່ເປັນເຊີບເວີ NTP ສູນກາງ, ແຈກຢາຍເວລາຂອງມັນໃຫ້ກັບທຸກກຸ່ມ, ດ້ວຍເຫດນີ້ການຊິ້ງເຊີບເວີທັງໝົດກັບກັນ. ຖ້າ ພະຍານ ລົ້ມເຫລວຫຼືຖືກໂດດດ່ຽວ, ຫຼັງຈາກນັ້ນຫນຶ່ງໃນເຄື່ອງແມ່ຂ່າຍຂອງກຸ່ມ (ພາຍໃນກຸ່ມ) ຈະເລີ່ມແຈກຢາຍເວລາຂອງມັນ. ການເກັບຂໍ້ມູນຊ່ວຍ ຕົວແທນ HTTP ຍົກຂຶ້ນມາ ພະຍານ, ດ້ວຍການຊ່ວຍເຫຼືອຂອງມັນ, ເຄື່ອງຈັກ virtual ອື່ນໆສາມາດເຂົ້າເຖິງບ່ອນເກັບມ້ຽນ Yum. ໃນຄວາມເປັນຈິງ, ການບໍລິການເຊັ່ນ: ເວລາທີ່ຖືກຕ້ອງແລະຕົວແທນສ່ວນໃຫຍ່ມັກຈະຖືກໂຮດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ອຸທິດຕົນ, ແຕ່ໃນບູດພວກເຂົາຖືກຈັດຢູ່ໃນ. ພະຍານ ພຽງແຕ່ເພື່ອຊ່ວຍປະຢັດຈໍານວນຂອງເຄື່ອງ virtual ແລະພື້ນທີ່.

ສະບັບ

v0. ເຮັດວຽກກັບ CentOS 7 ແລະ PostgreSQL 11 ໃນ VirtualBox 6.1.

ໂຄງສ້າງກຸ່ມ

ກຸ່ມທັງໝົດຖືກອອກແບບໃຫ້ຕັ້ງຢູ່ໃນສູນຂໍ້ມູນຫຼາຍແຫ່ງ, ຮວມເຂົ້າກັນເປັນເຄືອຂ່າຍຮາບພຽງດຽວ ແລະຕ້ອງທົນຕໍ່ຄວາມລົ້ມເຫຼວ ຫຼືການແຍກເຄືອຂ່າຍຂອງສູນຂໍ້ມູນດຽວ. ນັ້ນຄືເຫດຜົນ ແມ່ນບໍ່ເປັນໄປໄດ້ ໃຊ້ເພື່ອປ້ອງກັນ ສະໝອງແຕກ ເຕັກໂນໂລຊີ Pacemaker ມາດຕະຖານເອີ້ນວ່າ STONITH (Shoot the other node in the head) ຫຼື ຫນາມຫມາກຈັບ. ໂດຍເນື້ອແທ້ແລ້ວຂອງມັນ: ຖ້າ nodes ໃນ cluster ເລີ່ມສົງໃສວ່າມີບາງຢ່າງຜິດພາດກັບບາງ node, ມັນບໍ່ຕອບສະຫນອງຫຼືມີພຶດຕິກໍາທີ່ບໍ່ຖືກຕ້ອງ, ຫຼັງຈາກນັ້ນພວກເຂົາບັງຄັບມັນປິດມັນຜ່ານອຸປະກອນ "ພາຍນອກ", ຕົວຢ່າງເຊັ່ນບັດຄວບຄຸມ IPMI ຫຼື UPS. . ແຕ່ນີ້ຈະເຮັດວຽກພຽງແຕ່ໃນກໍລະນີທີ່, ໃນກໍລະນີຂອງຄວາມລົ້ມເຫລວດຽວ, ເຄື່ອງແມ່ຂ່າຍ IPMI ຫຼື UPS ຍັງສືບຕໍ່ເຮັດວຽກ. ໃນທີ່ນີ້ພວກເຮົາວາງແຜນທີ່ຈະປ້ອງກັນຄວາມລົ້ມເຫຼວຂອງໄພພິບັດຫຼາຍ, ເມື່ອສູນຂໍ້ມູນທັງຫມົດລົ້ມເຫລວ (ຕົວຢ່າງ, ສູນເສຍພະລັງງານ). ແລະດ້ວຍການປະຕິເສດດັ່ງກ່າວ, ທຸກສິ່ງທຸກຢ່າງ ສະໂຕນິທ-ອຸປະກອນ (IPMI, UPS, ແລະອື່ນໆ) ຈະບໍ່ເຮັດວຽກ.

ແທນທີ່ຈະ, ລະບົບແມ່ນອີງໃສ່ແນວຄວາມຄິດຂອງກຸ່ມ. ທຸກໆ nodes ມີສຽງ, ແລະພຽງແຕ່ຜູ້ທີ່ສາມາດເບິ່ງຫຼາຍກ່ວາເຄິ່ງຫນຶ່ງຂອງ nodes ທັງຫມົດສາມາດເຮັດວຽກໄດ້. ປະລິມານຂອງ "ເຄິ່ງ + 1" ນີ້ເອີ້ນວ່າ ກຸ່ມ. ຖ້າບໍ່ເຖິງ quorum, ຫຼັງຈາກນັ້ນ node ຕັດສິນໃຈວ່າມັນຢູ່ໃນການແຍກເຄືອຂ່າຍແລະຕ້ອງປິດຊັບພະຍາກອນຂອງມັນ, i.e. ນີ້ແມ່ນສິ່ງທີ່ມັນເປັນ ປ້ອງກັນສະໝອງແຕກ. ຖ້າຊອບແວທີ່ຮັບຜິດຊອບຕໍ່ພຶດຕິກໍານີ້ບໍ່ເຮັດວຽກ, ຕົວຢ່າງເຊັ່ນ, ອີງໃສ່ IPMI, ຈະຕ້ອງເຮັດວຽກ.

ຖ້າຈໍານວນຂອງ nodes ແມ່ນຄູ່ (ກຸ່ມຢູ່ໃນສອງສູນຂໍ້ມູນ), ຄວາມບໍ່ແນ່ນອນທີ່ເອີ້ນວ່າອາດຈະເກີດຂື້ນ. 50% / 50% (ຫ້າສິບຫ້າສິບ) ເມື່ອການແຍກເຄືອຂ່າຍແບ່ງກຸ່ມຢ່າງແນ່ນອນໃນເຄິ່ງຫນຶ່ງ. ດັ່ງນັ້ນ, ສໍາລັບຈໍານວນຄູ່ຂອງ nodes, ພວກເຮົາເພີ່ມ ອຸປະກອນກຸ່ມ ເປັນ daemon undemanding ທີ່ສາມາດໄດ້ຮັບການເປີດຕົວໃນເຄື່ອງ virtual ລາຄາຖືກທີ່ສຸດໃນສູນຂໍ້ມູນທີສາມ. ລາວໃຫ້ຄະແນນສຽງຂອງລາວກັບຫນຶ່ງໃນສ່ວນ (ທີ່ລາວເຫັນ), ແລະດັ່ງນັ້ນຈຶ່ງແກ້ໄຂຄວາມບໍ່ແນ່ນອນ 50% / 50%. ຂ້າ​ພະ​ເຈົ້າ​ຕັ້ງ​ຊື່​ເຊີບ​ເວີ​ທີ່​ອຸ​ປະ​ກອນ​ກຸ່ມ​ໂຄ​ຣຳ​ຈະ​ຖືກ​ເປີດ​ນຳ​ໃຊ້ ພະຍານ (ຄຳສັບຈາກ repmgr, ຂ້ອຍມັກມັນ).

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

Tuchanka1 (ວົງຈອນທີ່ມີການບີບອັດ)

ໂຄງປະກອບການ

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

ແຕ່ລະສູນຂໍ້ມູນມີເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ. ແຕ່ລະເຄື່ອງແມ່ຂ່າຍມີສອງຕົວຢ່າງ PostgreSQL (ໃນຄໍາສັບ PostgreSQL ເຂົາເຈົ້າເອີ້ນວ່າກຸ່ມ, ແຕ່ເພື່ອຫຼີກເວັ້ນການສັບສົນ, ຂ້າພະເຈົ້າຈະໂທຫາພວກເຂົາ instances (ໂດຍການປຽບທຽບກັບຖານຂໍ້ມູນອື່ນໆ), ແລະຂ້າພະເຈົ້າຈະໂທຫາພຽງແຕ່ກຸ່ມ Pacemaker clusters). ຕົວຢ່າງຫນຶ່ງດໍາເນີນການໃນຮູບແບບຕົ້ນສະບັບ, ແລະພຽງແຕ່ມັນໃຫ້ບໍລິການ (ພຽງແຕ່ IP ທີ່ເລື່ອນໄດ້ນໍາໄປສູ່ມັນ). ຕົວຢ່າງທີສອງເຮັດວຽກເປັນທາດສໍາລັບສູນຂໍ້ມູນທີສອງ, ແລະຈະໃຫ້ບໍລິການພຽງແຕ່ຖ້າແມ່ແບບຂອງມັນລົ້ມເຫລວ. ເນື່ອງຈາກເວລາສ່ວນໃຫຍ່ມີພຽງແຕ່ຫນຶ່ງຕົວຢ່າງອອກຈາກສອງ (ແມ່ບົດ) ຈະໃຫ້ບໍລິການ (ປະຕິບັດການຮ້ອງຂໍ), ຊັບພະຍາກອນຂອງເຄື່ອງແມ່ຂ່າຍທັງຫມົດແມ່ນ optimized ສໍາລັບແມ່ບົດ (ຫນ່ວຍຄວາມຈໍາຖືກຈັດສັນສໍາລັບ share_buffers cache, ແລະອື່ນໆ), ແຕ່ດັ່ງນັ້ນຕົວຢ່າງທີສອງ. ຍັງມີຊັບພະຍາກອນພຽງພໍ (ເຖິງແມ່ນວ່າສໍາລັບການປະຕິບັດທີ່ດີທີ່ສຸດໂດຍຜ່ານ cache ຂອງລະບົບໄຟລ໌) ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງສູນຂໍ້ມູນຫນຶ່ງ. ສໍາລອງບໍ່ໄດ້ໃຫ້ບໍລິການ (ບໍ່ປະຕິບັດການຮ້ອງຂໍການອ່ານເທົ່ານັ້ນ) ໃນລະຫວ່າງການປະຕິບັດງານປົກກະຕິຂອງກຸ່ມ, ດັ່ງນັ້ນບໍ່ມີສົງຄາມສໍາລັບຊັບພະຍາກອນກັບແມ່ບົດໃນເຄື່ອງດຽວກັນ.

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

ຄວາມລົ້ມເຫຼວທີ່ຈະເປັນພະຍານ

ຄວາມລົ້ມເຫຼວທີ່ຈະເປັນພະຍານ (ອຸປະກອນກຸ່ມ) ຂ້າພະເຈົ້າຈະພິຈາລະນາພຽງແຕ່ສໍາລັບກຸ່ມ Tuchanka1, ກັບສິ່ງອື່ນໆທັງຫມົດມັນຈະເປັນເລື່ອງດຽວກັນ. ຖ້າພະຍານລົ້ມເຫລວ, ບໍ່ມີຫຍັງຈະປ່ຽນແປງໃນໂຄງສ້າງຂອງກຸ່ມ, ທຸກສິ່ງທຸກຢ່າງຈະສືບຕໍ່ເຮັດວຽກຄືກັນກັບມັນ. ​ແຕ່​ກຸ່ມ​ໂຄ​ຣຳ​ຈະ​ກາຍ​ເປັນ 2 ​ໃນ 3 ​ຄະ​ແນນ, ​ແລະ​ເພາະ​ສະ​ນັ້ນ​ຄວາມ​ລົ້ມ​ເຫຼວ​ໃນ​ຄັ້ງ​ຕໍ່​ມາ​ຈະ​ເປັນ​ອັນຕະລາຍ​ຮ້າຍ​ແຮງ​ຕໍ່​ກຸ່ມ. ຍັງ​ຈະ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ແກ້​ໄຂ​ຢ່າງ​ຮີບ​ດ່ວນ.

Tuchanka1 ການປະຕິເສດ

ຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງໃນສູນຂໍ້ມູນສໍາລັບ Tuchanka1. ໃນ​ກໍ​ລະ​ນີ​ນີ້ ພະຍານ ໂຫວດໃຫ້ຄະແນນສຽງທີ່ສອງຢູ່ໃນສູນຂໍ້ມູນທີສອງ. ຢູ່ທີ່ນັ້ນ, ອະດີດທາດກາຍເປັນແມ່ບົດ, ດັ່ງນັ້ນ, ແມ່ບົດທັງສອງເຮັດວຽກຢູ່ໃນເຄື່ອງແມ່ຂ່າຍດຽວກັນແລະທັງສອງ IP ທີ່ເລື່ອນໄດ້ຊີ້ໃຫ້ເຫັນເຖິງພວກເຂົາ.

Tuchanka2 (ຄລາສສິກ)

ໂຄງປະກອບການ

ໂຄງການຄລາສສິກຂອງສອງ nodes. ນາຍ​ເຮັດ​ວຽກ​ຢູ່​ຄົນ​ໜຶ່ງ, ຂ້າ​ໃຊ້​ຄົນ​ທີ​ສອງ. ທັງສອງສາມາດປະຕິບັດການຮ້ອງຂໍ (ສໍາລອງແມ່ນອ່ານເທົ່ານັ້ນ), ດັ່ງນັ້ນທັງສອງໄດ້ຖືກຊີ້ໃຫ້ເຫັນໂດຍ float IP: krogan2 ແມ່ນແມ່ບົດ, krogan2s1 ແມ່ນສໍາລອງ. ທັງນາຍແລະຂ້າໃຊ້ຈະມີຄວາມອົດທົນຕໍ່ຄວາມຜິດ.

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

Tuchanka2 ການປະຕິເສດ

ຖ້າຫນຶ່ງໃນສູນຂໍ້ມູນລົ້ມເຫລວ ພະຍານ ລົງຄະແນນສຽງສໍາລັບອັນທີສອງ. ໃນສູນຂໍ້ມູນດຽວທີ່ເຮັດວຽກ, ແມ່ບົດຈະຖືກຍົກຂຶ້ນມາ, ແລະ IPs ທີ່ເລື່ອນໄດ້ທັງສອງຈະຊີ້ໃຫ້ເຫັນເຖິງມັນ: ແມ່ບົດແລະສໍາລອງ. ແນ່ນອນ, ຕົວຢ່າງຕ້ອງໄດ້ຮັບການຕັ້ງຄ່າໃນລັກສະນະທີ່ມັນມີຊັບພະຍາກອນພຽງພໍ (ຈໍາກັດການເຊື່ອມຕໍ່, ແລະອື່ນໆ) ເພື່ອຮັບເອົາການເຊື່ອມຕໍ່ແລະການຮ້ອງຂໍທັງຫມົດຈາກແມ່ບົດແລະ slave float IP ໃນເວລາດຽວກັນ. ນັ້ນແມ່ນ, ໃນລະຫວ່າງການປະຕິບັດງານປົກກະຕິ, ມັນຄວນຈະມີຂອບເຂດຈໍາກັດພຽງພໍ.

Tuchanka4 (ຂ້າ​ໃຊ້​ຫຼາຍ​)

ໂຄງປະກອບການ

ແລ້ວອີກອັນໜຶ່ງ. ມີຖານຂໍ້ມູນທີ່ໄດ້ຮັບຄໍາຮ້ອງຂໍການອ່ານຫຼາຍເທົ່ານັ້ນ (ກໍລະນີປົກກະຕິຂອງເວັບໄຊທ໌ທີ່ມີການໂຫຼດສູງ). Tuchanka4 ແມ່ນສະຖານະການທີ່ອາດຈະມີສາມຫຼືຫຼາຍກວ່າສໍາລອງເພື່ອຈັດການກັບຄໍາຮ້ອງຂໍດັ່ງກ່າວ, ແຕ່ຍັງບໍ່ຫຼາຍ. ດ້ວຍຈໍານວນຂ້າທາດຫຼາຍ, ມັນຈະມີຄວາມຈໍາເປັນທີ່ຈະປະດິດລະບົບການຈໍາລອງແບບລໍາດັບຊັ້ນ. ໃນກໍລະນີຕໍາ່ສຸດທີ່ (ໃນຮູບ), ແຕ່ລະສູນຂໍ້ມູນມີສອງເຄື່ອງແມ່ຂ່າຍ, ແຕ່ລະຄົນມີຕົວຢ່າງ PostgreSQL.

ຄຸນນະສົມບັດອີກອັນຫນຶ່ງຂອງໂຄງການນີ້ແມ່ນວ່າມັນເປັນໄປໄດ້ທີ່ຈະຈັດຫນຶ່ງ replication synchronous. ມັນໄດ້ຖືກຕັ້ງຄ່າໃຫ້ replicate, ຖ້າເປັນໄປໄດ້, ກັບສູນຂໍ້ມູນອື່ນ, ແທນທີ່ຈະເປັນ replica ໃນສູນຂໍ້ມູນດຽວກັນກັບຕົ້ນສະບັບ. ແມ່ບົດແລະທາດແຕ່ລະຄົນຖືກຊີ້ໄປຫາ IP ທີ່ເລື່ອນໄດ້. ໂຊກດີ, ລະຫວ່າງສໍາລອງມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະດຸ່ນດ່ຽງການຮ້ອງຂໍ somehow sql proxy, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນດ້ານລູກຄ້າ. ປະເພດຕ່າງໆຂອງລູກຄ້າອາດຈະຕ້ອງການປະເພດຕ່າງໆ sql proxy, ແລະພຽງແຕ່ຜູ້ພັດທະນາລູກຄ້າຮູ້ວ່າໃຜຕ້ອງການອັນໃດ. ຟັງຊັນນີ້ສາມາດຖືກປະຕິບັດໄດ້ໂດຍ daemon ພາຍນອກຫຼືໂດຍຫ້ອງສະຫມຸດລູກຄ້າ (ສະນຸກເກີການເຊື່ອມຕໍ່), ແລະອື່ນໆ. ທັງໝົດນີ້ໄປເກີນຫົວຂໍ້ຂອງກຸ່ມຖານຂໍ້ມູນທີ່ລົ້ມເຫລວ (failover SQL proxy ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ເປັນ​ອິດ​ສະ​ຫຼະ​, ຮ່ວມ​ກັນ​ກັບ​ຄວາມ​ຜິດ​ພາດ​ຂອງ​ລູກ​ຄ້າ​)​.

Tuchanka4 ການປະຕິເສດ

ຖ້າສູນຂໍ້ມູນຫນຶ່ງ (i.e., ສອງເຄື່ອງແມ່ຂ່າຍ) ລົ້ມເຫລວ, ພະຍານ vote ສໍາລັບທີສອງ. ດັ່ງນັ້ນ, ມີສອງເຄື່ອງແມ່ຂ່າຍທີ່ແລ່ນຢູ່ໃນສູນຂໍ້ມູນທີສອງ: ຫນຶ່ງແມ່ນແລ່ນແມ່ບົດ, ແລະແມ່ບົດ float IP ຊີ້ໃຫ້ເຫັນມັນ (ສໍາລັບການໄດ້ຮັບການຮ້ອງຂໍການອ່ານຂຽນ); ແລະໃນເຊີບເວີທີສອງມີ slave ແລ່ນກັບ replication synchronous, ແລະຫນຶ່ງໃນ slave float IPs ຊີ້ໃຫ້ເຫັນມັນ (ສໍາລັບການຮ້ອງຂໍການອ່ານເທົ່ານັ້ນ).

ສິ່ງທໍາອິດທີ່ຄວນສັງເກດແມ່ນວ່າບໍ່ແມ່ນທັງຫມົດ slave float IPs ຈະເປັນພະນັກງານ, ແຕ່ວ່າມີພຽງແຕ່ຫນຶ່ງ. ແລະເພື່ອເຮັດວຽກກັບມັນຢ່າງຖືກຕ້ອງ, ມັນຈະມີຄວາມຈໍາເປັນ sql proxy redirected ການຮ້ອງຂໍທັງຫມົດໄປຫາ IP ທີ່ຍັງເຫຼືອພຽງແຕ່ float; ແລະຖ້າ sql proxy ບໍ່, ຫຼັງຈາກນັ້ນທ່ານສາມາດລາຍຊື່ສໍາລອງ IP ລອຍທັງຫມົດທີ່ແຍກອອກດ້ວຍເຄື່ອງໝາຍຈຸດຢູ່ໃນ URL ເຊື່ອມຕໍ່. ໃນກໍລະນີນີ້, ກັບ libpq ການເຊື່ອມຕໍ່ຈະເປັນ IP ທີ່ເຮັດວຽກທໍາອິດ, ນີ້ແມ່ນເຮັດໃນລະບົບການທົດສອບອັດຕະໂນມັດ. ບາງທີຢູ່ໃນຫ້ອງສະຫມຸດອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, JDBC, ນີ້ຈະບໍ່ເຮັດວຽກແລະມີຄວາມຈໍາເປັນ sql proxy. ນີ້ແມ່ນເຮັດໄດ້ເພາະວ່າ IPs ລອຍສໍາລັບສໍາລອງຖືກຫ້າມບໍ່ໃຫ້ຖືກຍົກຂຶ້ນມາພ້ອມໆກັນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຫນຶ່ງ, ດັ່ງນັ້ນພວກມັນຈະຖືກແຈກຢາຍຢ່າງເທົ່າທຽມກັນລະຫວ່າງເຄື່ອງແມ່ຂ່າຍຂອງສໍາລອງຖ້າມີຫຼາຍຂອງພວກເຂົາແລ່ນ.

ອັນທີສອງ: ເຖິງແມ່ນວ່າໃນກໍລະນີທີ່ສູນຂໍ້ມູນລົ້ມເຫລວ, ການຈໍາລອງແບບ synchronous ຈະຖືກຮັກສາໄວ້. ແລະເຖິງແມ່ນວ່າຄວາມລົ້ມເຫລວຂັ້ນສອງເກີດຂື້ນ, ນັ້ນແມ່ນ, ຫນຶ່ງໃນສອງເຄື່ອງແມ່ຂ່າຍໃນສູນຂໍ້ມູນທີ່ຍັງເຫຼືອລົ້ມເຫລວ, ກຸ່ມ, ເຖິງແມ່ນວ່າມັນຈະຢຸດໃຫ້ບໍລິການ, ຈະຍັງຄົງຮັກສາຂໍ້ມູນກ່ຽວກັບການເຮັດທຸລະກໍາທີ່ຫມັ້ນສັນຍາທັງຫມົດທີ່ມັນໃຫ້ການຢືນຢັນຄໍາຫມັ້ນສັນຍາ. (ຈະບໍ່ມີຂໍ້ມູນການສູນເສຍໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂັ້ນສອງ).

Tuchanka3 (3 ສູນ​ຂໍ້​ມູນ​)

ໂຄງປະກອບການ

ນີ້ແມ່ນກຸ່ມສໍາລັບສະຖານະການທີ່ມີສາມສູນຂໍ້ມູນທີ່ເຮັດວຽກຢ່າງເຕັມທີ່, ແຕ່ລະຄົນມີເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນທີ່ເຮັດວຽກຢ່າງເຕັມທີ່. ໃນ​ກໍ​ລະ​ນີ​ນີ້ ອຸປະກອນກຸ່ມ ບໍ່ຈໍາເປັນ. ສູນຂໍ້ມູນຫນຶ່ງແມ່ນພະນັກງານໂດຍນາຍ, ອີກສອງຄົນແມ່ນພະນັກງານໂດຍສໍາລອງ. Replication ແມ່ນ synchronous, ປະເພດ ANY (slave1, slave2), ນັ້ນແມ່ນ, ລູກຄ້າຈະໄດ້ຮັບການຢືນຢັນເມື່ອສໍາລອງຄົນທໍາອິດທີ່ຕອບສະຫນອງວ່າລາວໄດ້ຍອມຮັບຄໍາຫມັ້ນສັນຍາ. ຊັບພະຍາກອນແມ່ນສະແດງໂດຍ IP ລອຍຫນຶ່ງສໍາລັບແມ່ບົດແລະສອງສໍາລັບສໍາລອງ. ບໍ່ເຫມືອນກັບ Tuchanka4, ທັງສາມ IP float ແມ່ນມີຄວາມທົນທານຕໍ່ຄວາມຜິດ. ເພື່ອດຸ່ນດ່ຽງການສອບຖາມ SQL ແບບອ່ານເທົ່ານັ້ນທີ່ທ່ານສາມາດນໍາໃຊ້ sql proxy (ມີຄວາມທົນທານຕໍ່ຄວາມຜິດແຍກຕ່າງຫາກ), ຫຼືມອບຫມາຍ IP ທີ່ເລື່ອນໄດ້ຫນຶ່ງໃຫ້ແກ່ລູກຄ້າເຄິ່ງຫນຶ່ງ, ແລະອີກເຄິ່ງຫນຶ່ງເປັນທີສອງ.

Tuchanka3 ການປະຕິເສດ

ຖ້າສູນຂໍ້ມູນຫນຶ່ງລົ້ມເຫລວ, ສອງຍັງຄົງຢູ່. ໃນຫນຶ່ງ, IP ຂອງແມ່ບົດແລະ float ຈາກແມ່ບົດໄດ້ຖືກຍົກຂຶ້ນມາ, ໃນທີສອງ - slave ແລະທັງສອງ slave float IPs (ຕົວຢ່າງຕ້ອງມີສະຫງວນສອງເທົ່າຂອງຊັບພະຍາກອນເພື່ອຍອມຮັບການເຊື່ອມຕໍ່ທັງຫມົດຈາກທັງສອງ slave float IPs). ການຈຳລອງແບບ synchronous ລະຫວ່າງນາຍ ແລະຂ້າທາດ. ນອກຈາກນີ້, ກຸ່ມຈະຊ່ວຍປະຢັດຂໍ້ມູນກ່ຽວກັບການເຮັດທຸລະກໍາທີ່ຫມັ້ນສັນຍາແລະຢືນຢັນ (ຈະບໍ່ສູນເສຍຂໍ້ມູນ) ໃນກໍລະນີທີ່ມີການທໍາລາຍສູນຂໍ້ມູນສອງ (ຖ້າພວກມັນບໍ່ໄດ້ຖືກທໍາລາຍພ້ອມໆກັນ).

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

ລະບົບການທົດສອບອັດຕະໂນມັດ

ເພື່ອທົດສອບຄວາມທົນທານຄວາມຜິດຂອງກຸ່ມໂດຍການຈໍາລອງຄວາມຜິດຕ່າງໆ, ລະບົບການທົດສອບອັດຕະໂນມັດໄດ້ຖືກສ້າງຂື້ນ. ເປີດຕົວໂດຍ script test/failure. script ສາມາດໃຊ້ເວລາເປັນຕົວກໍານົດການຈໍານວນຂອງກຸ່ມທີ່ທ່ານຕ້ອງການທີ່ຈະທົດສອບ. ສໍາລັບຕົວຢ່າງ, ຄໍາສັ່ງນີ້:

test/failure 2 3

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

terminal ໄດ້ຖືກແບ່ງອອກເປັນຖັນຕາມຈໍານວນຂອງກຸ່ມທີ່ຖືກທົດສອບໂດຍຄ່າເລີ່ມຕົ້ນ (ໃນ screenshot) ມີສີ່. ຂ້ອຍຈະອະທິບາຍເນື້ອໃນຂອງຄໍລໍາໂດຍໃຊ້ຕົວຢ່າງຂອງ Tuchanka2. ແຜງໃນພາບໜ້າຈໍແມ່ນເປັນຕົວເລກ:

1. ສະຖິຕິການທົດສອບຖືກສະແດງຢູ່ທີ່ນີ້. ຖັນ:
   • ຄວາມລົ້ມເຫຼວ — ຊື່​ຂອງ​ການ​ທົດ​ສອບ (ຫນ້າ​ທີ່​ໃນ​ຕົວ​ອັກ​ສອນ​) ທີ່​ເຮັດ​ຕາມ​ຄວາມ​ຜິດ​ພາດ​.
   • ຕິກິຣິຍາ — ເວ​ລາ​ສະ​ເລ່ຍ​ເລກ​ຄະ​ນິດ​ໃນ​ວິ​ນາ​ທີ​ທີ່​ກຸ່ມ​ໄດ້​ຟື້ນ​ຕົວ​ການ​ທໍາ​ງານ​ຂອງ​ຕົນ​. ມັນຖືກວັດແທກຕັ້ງແຕ່ເລີ່ມຕົ້ນຂອງສະຄຣິບທີ່ຈຳລອງຄວາມຜິດໄປຈົນເຖິງປັດຈຸບັນທີ່ກຸ່ມກຸ່ມຟື້ນຟູການເຮັດວຽກຂອງມັນ ແລະສາມາດສືບຕໍ່ໃຫ້ບໍລິການໄດ້. ຖ້າເວລາສັ້ນຫຼາຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ຫົກວິນາທີ (ອັນນີ້ເກີດຂື້ນໃນກຸ່ມທີ່ມີທາດຫຼາຍ (Tuchanka3 ແລະ Tuchanka4)), ນີ້ຫມາຍຄວາມວ່າຄວາມຜິດແມ່ນຢູ່ໃນສໍາລອງທີ່ບໍ່ກົງກັນແລະບໍ່ມີຜົນກະທົບຕໍ່ການປະຕິບັດໃນທາງໃດກໍ່ຕາມ; ປຸ່ມລັດກຸ່ມ.
   • ການບ່ຽງເບນ — ສະ​ແດງ​ໃຫ້​ເຫັນ​ການ​ແຜ່​ກະ​ຈາຍ (ຄວາມ​ຖືກ​ຕ້ອງ​) ຂອງ​ມູນ​ຄ່າ​ ຕິກິຣິຍາ ການນໍາໃຊ້ວິທີການ deviation ມາດຕະຖານ.
   • ນັບ — ການທົດສອບນີ້ຖືກປະຕິບັດຈັກເທື່ອ.
2. ບັນທຶກສັ້ນຊ່ວຍໃຫ້ທ່ານສາມາດປະເມີນສິ່ງທີ່ກຸ່ມກໍາລັງເຮັດໃນປັດຈຸບັນ. ຕົວເລກ iteration (ການທົດສອບ), ເວລາແລະຊື່ຂອງການດໍາເນີນງານແມ່ນສະແດງ. ການແລ່ນດົນເກີນໄປ (> 5 ນາທີ) ສະແດງເຖິງບັນຫາ.
3. ຫົວໃຈ (ຫົວໃຈ) - ເວລາປະຈຸບັນ. ສໍາລັບການປະເມີນສາຍຕາຂອງການປະຕິບັດ ແມ່ບົດ ເວລາປະຈຸບັນແມ່ນຂຽນໃສ່ຕາຕະລາງຂອງມັນຢ່າງຕໍ່ເນື່ອງໂດຍໃຊ້ແມ່ບົດ IP ລອຍ. ຖ້າປະສົບຜົນສໍາເລັດ, ຜົນໄດ້ຮັບຈະສະແດງຢູ່ໃນກະດານນີ້.
4. ຫຼິ້ນໃຫ້ເກີນແມ່ນ (ກໍາມະຈອນ) - "ເວລາປະຈຸບັນ", ເຊິ່ງໄດ້ຖືກບັນທຶກໄວ້ໃນເມື່ອກ່ອນໂດຍ script ຫົວໃຈ ກັບຕົ້ນສະບັບ, ໃນປັດຈຸບັນອ່ານຈາກ ທາດ ຜ່ານ IP ລອຍຂອງມັນ. ອະນຸຍາດໃຫ້ທ່ານສາມາດປະເມີນປະສິດທິພາບຂອງສໍາລອງແລະການຈໍາລອງແບບ. ໃນ Tuchanka1 ບໍ່ມີສໍາລອງທີ່ມີ IP ລອຍ (ບໍ່ມີສໍາລອງໃຫ້ບໍລິການ), ແຕ່ມີສອງຕົວຢ່າງ (DBs), ດັ່ງນັ້ນມັນຈະບໍ່ສະແດງຢູ່ທີ່ນີ້. ຫຼິ້ນໃຫ້ເກີນແມ່ນແລະ ຫົວໃຈ ຕົວຢ່າງທີສອງ.
5. ການຕິດຕາມສຸຂະພາບຂອງກຸ່ມໂດຍໃຊ້ປະໂຫຍດ pcs mon. ສະແດງໃຫ້ເຫັນໂຄງສ້າງ, ການແຜ່ກະຈາຍຂອງຊັບພະຍາກອນໃນທົ່ວ nodes ແລະຂໍ້ມູນທີ່ເປັນປະໂຫຍດອື່ນໆ.
6. ການຕິດຕາມລະບົບຈາກແຕ່ລະເຄື່ອງ virtual ໃນ cluster ແມ່ນສະແດງຢູ່ທີ່ນີ້. ອາດຈະມີແຜງດັ່ງກ່າວຫຼາຍຂື້ນຂຶ້ນກັບວ່າມີຈັກ virtual machines ທີ່ cluster ມີ. ສອງກຣາຟ ໂຫຼດ CPU (ເຄື່ອງ virtual ມີສອງໂປເຊດເຊີ), ຊື່ເຄື່ອງ virtual, ໂຫຼດລະບົບ (ມີຊື່ວ່າ Load Average ເນື່ອງຈາກວ່າມັນສະເລ່ຍຫຼາຍກວ່າ 5, 10 ແລະ 15 ນາທີ), ຂໍ້ມູນຂະບວນການ ແລະ ການຈັດສັນໜ່ວຍຄວາມຈຳ.
7. ການຕິດຕາມຂອງ script ປະຕິບັດການທົດສອບ. ໃນກໍລະນີຂອງຄວາມຜິດປົກກະຕິ - ການຂັດຂວາງການດໍາເນີນງານຢ່າງກະທັນຫັນຫຼືວົງຈອນການລໍຖ້າທີ່ບໍ່ມີສິ້ນສຸດ - ທີ່ນີ້ທ່ານສາມາດເບິ່ງເຫດຜົນສໍາລັບພຶດຕິກໍານີ້.

ການທົດສອບແມ່ນດໍາເນີນໃນສອງຂັ້ນຕອນ. ຫນ້າທໍາອິດ, script ໂດຍຜ່ານການທົດສອບທຸກປະເພດ, random ເລືອກເຄື່ອງ virtual ເພື່ອນໍາໃຊ້ການທົດສອບນີ້. ຫຼັງ​ຈາກ​ນັ້ນ​, ຮອບ​ວຽນ​ການ​ທົດ​ສອບ​ທີ່​ບໍ່​ສິ້ນ​ສຸດ​ແມ່ນ​ປະ​ຕິ​ບັດ​, ເຄື່ອງ virtual ແລະ​ຄວາມ​ຜິດ​ພາດ​ໄດ້​ຖືກ​ຄັດ​ເລືອກ​ແບບ​ສຸ່ມ​ໃນ​ແຕ່​ລະ​ຄັ້ງ​. ການຢຸດເຊົາຢ່າງກະທັນຫັນຂອງສະຄິບທົດສອບ (ກະດານລຸ່ມ) ຫຼືການລໍຄອຍທີ່ບໍ່ມີທີ່ສິ້ນສຸດ (> ເວລາປະຕິບັດ 5 ນາທີສໍາລັບການດໍາເນີນການຫນຶ່ງ, ນີ້ສາມາດເຫັນໄດ້ໃນການຕິດຕາມ) ຊີ້ໃຫ້ເຫັນວ່າບາງການທົດສອບໃນກຸ່ມນີ້ລົ້ມເຫລວ.

ແຕ່ລະການທົດສອບປະກອບດ້ວຍການດໍາເນີນງານດັ່ງຕໍ່ໄປນີ້:

1. ເປີດໃຊ້ຟັງຊັນທີ່ຈຳລອງຄວາມຜິດ.
2. ພ້ອມທີ່ຈະ? — ລໍ​ຖ້າ​ໃຫ້​ກຸ່ມ​ທີ່​ຈະ​ໄດ້​ຮັບ​ການ​ຟື້ນ​ຟູ (ເມື່ອ​ການ​ບໍ​ລິ​ການ​ທັງ​ຫມົດ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ສະ​ຫນອງ​ໃຫ້​)​.
3. ສະ​ແດງ​ການ​ຫມົດ​ເວ​ລາ​ການ​ຟື້ນ​ຕົວ​ຂອງ​ກຸ່ມ (ຕິກິຣິຍາ).
4. ແກ້ໄຂ - ກຸ່ມກໍາລັງຖືກ "ສ້ອມແປງ." ຫຼັງຈາກນັ້ນ, ມັນຄວນຈະກັບຄືນສູ່ສະພາບທີ່ເຮັດວຽກຢ່າງເຕັມທີ່ແລະກຽມພ້ອມສໍາລັບການຜິດປົກກະຕິຕໍ່ໄປ.

ນີ້ແມ່ນບັນຊີລາຍຊື່ຂອງການທົດສອບທີ່ມີຄໍາອະທິບາຍກ່ຽວກັບສິ່ງທີ່ເຂົາເຈົ້າເຮັດ:

• ForkBomb: ສ້າງ "ອອກຈາກຄວາມຊົງຈໍາ" ໂດຍໃຊ້ລູກລະເບີດຂອງສ້ອມ.
• ນອກພື້ນທີ່: ຮາດໄດເຕັມ. ແຕ່ການທົດສອບແມ່ນແທນທີ່ຈະເປັນສັນຍາລັກ;
• Postgres-ຂ້າ: ຂ້າ PostgreSQL ດ້ວຍຄໍາສັ່ງ killall -KILL postgres.
• Postgres-STOP: ວາງຄໍາສັ່ງ PostgreSQL killall -STOP postgres.
• ພະລັງງານ: "de-energizes" ເຄື່ອງ virtual ດ້ວຍຄໍາສັ່ງ VBoxManage controlvm "виртуалка" poweroff.
• ຕັ້ງ​ຄ່າ: overloads the virtual machine with the command VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspends SBD demon ກັບຄໍາສັ່ງ killall -STOP sbd.
• ປິດ​ເຄື່ອງ: ສົ່ງຄໍາສັ່ງໄປຍັງເຄື່ອງ virtual ຜ່ານ SSH systemctl poweroff, ລະບົບປິດລົງຢ່າງສະຫງ່າງາມ.
• ຍົກເລີກການເຊື່ອມຕໍ່: ການແຍກເຄືອຂ່າຍ, ຄໍາສັ່ງ VBoxManage controlvm "виртуалка" setlinkstate1 off.

ສໍາເລັດການທົດສອບໂດຍໃຊ້ຄໍາສັ່ງ tmux ມາດຕະຖານ "kill-window" Ctrl-b &, ຫຼືຄໍາສັ່ງ "detach-client". Ctrl-b ງ: ໃນຈຸດນີ້ການທົດສອບສິ້ນສຸດລົງ, tmux ປິດ, ເຄື່ອງ virtual ປິດ.

ບັນຫາທີ່ຖືກກໍານົດໃນລະຫວ່າງການທົດສອບ

• ໃນເວລານີ້ watchdog demon sbd ເຮັດວຽກກ່ຽວກັບການຢຸດ daemon ສັງເກດເຫັນ, ແຕ່ບໍ່ແຊ່ແຂງໃຫ້ເຂົາເຈົ້າ. ແລະ, ດັ່ງນັ້ນ, ຄວາມຜິດທີ່ນໍາໄປສູ່ການ freezing ເທົ່ານັ້ນ ໂຄໂຣຊິ້ງ и ມ້ານໍາ, ແຕ່ບໍ່ຫ້ອຍ sbd. ສໍາລັບການກວດສອບ ໂຄໂຣຊິ້ງ ມີແລ້ວ PR#83 (ຢູ່ GitHub ທີ່ sbd), ຍອມຮັບກັບກະທູ້ ຕົ້ນສະບັບ. ພວກເຂົາເຈົ້າສັນຍາ (ໃນ PR # 83) ວ່າຈະມີບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນສໍາລັບ Pacemaker, ຂ້າພະເຈົ້າຫວັງວ່າໂດຍ Red Hat 8 ຈະ​ເຮັດ. ແຕ່ "ຄວາມຜິດປົກກະຕິ" ດັ່ງກ່າວເປັນການຄາດເດົາແລະສາມາດຖືກຈໍາລອງໄດ້ງ່າຍໂດຍໃຊ້, ສໍາລັບຕົວຢ່າງ, killall -STOP corosync, ແຕ່ບໍ່ເຄີຍພົບໃນຊີວິດຈິງ.

• У ມ້ານໍາ ໃນ​ສະ​ບັບ​ສໍາ​ລັບ​ການ​ CentOS 7 ຕັ້ງ​ບໍ່​ຖືກ​ຕ້ອງ​ sync_timeout у ອຸປະກອນກຸ່ມ, ດັ່ງນັ້ນ ຖ້າ​ຫາກ​ວ່າ​ຫນຶ່ງ node ລົ້ມ​ເຫຼວ, ມີ​ບາງ​ຄວາມ​ເປັນ​ໄປ​ໄດ້​ບາງ node ທີ່​ສອງ​ຍັງ rebooted, ທີ່ແມ່ບົດໄດ້ຖືກ supposed ຍ້າຍອອກ. ປິ່ນປົວໂດຍການຂະຫຍາຍໃຫຍ່ຂື້ນ sync_timeout у ອຸປະກອນກຸ່ມ ໃນ​ລະ​ຫວ່າງ​ການ​ນໍາ​ໃຊ້ (ໃນ script setup/setup1). ການແກ້ໄຂນີ້ບໍ່ໄດ້ຮັບການຍອມຮັບໂດຍນັກພັດທະນາ ມ້ານໍາແທນທີ່ຈະ, ພວກເຂົາສັນຍາວ່າຈະອອກແບບໂຄງສ້າງພື້ນຖານໃຫມ່ໃນລັກສະນະດັ່ງກ່າວ (ໃນບາງອະນາຄົດທີ່ບໍ່ໄດ້ກໍານົດ) ທີ່ເວລາຫມົດເວລານີ້ຈະຖືກຄິດໄລ່ໂດຍອັດຕະໂນມັດ.

• ຖ້າການຕັ້ງຄ່າຖານຂໍ້ມູນກໍານົດວ່າ LC_MESSAGES (ຂໍ້ຄວາມ) ສາມາດໃຊ້ Unicode, e.g. ru_RU.UTF-8, ຫຼັງຈາກນັ້ນໃນຕອນເລີ່ມຕົ້ນ ໄປສະນີ ໃນສະພາບແວດລ້ອມທີ່ທ້ອງຖິ່ນບໍ່ແມ່ນ UTF-8, ເວົ້າໃນສະພາບແວດລ້ອມທີ່ຫວ່າງເປົ່າ (ທີ່ນີ້ ເຄື່ອງຈັງຫວະ+pgsqlms(paf) ແລ່ນ ໄປສະນີ), ແລ້ວ ບັນທຶກຈະມີເຄື່ອງໝາຍຖາມແທນຕົວອັກສອນ UTF-8. ນັກພັດທະນາ PostgreSQL ບໍ່ໄດ້ຕົກລົງກ່ຽວກັບສິ່ງທີ່ຕ້ອງເຮັດໃນກໍລະນີນີ້. ມັນຄ່າໃຊ້ຈ່າຍ, ທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງ LC_MESSAGES=en_US.UTF-8 ເມື່ອຕັ້ງຄ່າ (ສ້າງ) ຕົວຢ່າງຖານຂໍ້ມູນ.

• ຖ້າ wal_receiver_timeout ຖືກກໍານົດ (ໂດຍຄ່າເລີ່ມຕົ້ນມັນແມ່ນ 60s), ຫຼັງຈາກນັ້ນໃນລະຫວ່າງການທົດສອບ PostgreSQL-STOP ໃນແມ່ບົດໃນກຸ່ມ tuchanka3 ແລະ tuchanka4 replication ບໍ່ໄດ້ເຊື່ອມຕໍ່ໃຫມ່ກັບຕົ້ນສະບັບໃຫມ່. Replication ຢູ່ທີ່ນັ້ນແມ່ນ synchronous, ສະນັ້ນບໍ່ພຽງແຕ່ສໍາລອງຢຸດເຊົາ, ແຕ່ຍັງຕົ້ນສະບັບໃຫມ່. ເຮັດວຽກໂດຍການຕັ້ງຄ່າ wal_receiver_timeout=0 ເມື່ອຕັ້ງຄ່າ PostgreSQL.

• ບາງຄັ້ງຂ້າພະເຈົ້າສັງເກດເຫັນ replication freezes ໃນ PostgreSQL ໃນການທົດສອບ ForkBomb (ຄວາມຈໍາ overflow). ຫຼັງຈາກ ForkBomb, ບາງຄັ້ງຂ້າທາດອາດຈະບໍ່ເຊື່ອມຕໍ່ກັບແມ່ບົດໃຫມ່. ຂ້າພະເຈົ້າພຽງແຕ່ໄດ້ພົບນີ້ຢູ່ໃນກຸ່ມ tuchanka3 ແລະ tuchanka4, ບ່ອນທີ່ແມ່ບົດ froze ເນື່ອງຈາກການ replication synchronous. ບັນຫາໄດ້ຫາຍໄປດ້ວຍຕົວມັນເອງຫຼັງຈາກເວລາດົນນານ (ປະມານສອງຊົ່ວໂມງ). ຕ້ອງການການຄົ້ນຄວ້າເພີ່ມເຕີມເພື່ອແກ້ໄຂນີ້. ອາການແມ່ນຄ້າຍຄືກັນກັບແມງໄມ້ທີ່ຜ່ານມາ, ເຊິ່ງເກີດຈາກເຫດຜົນທີ່ແຕກຕ່າງກັນ, ແຕ່ມີຜົນສະທ້ອນດຽວກັນ.

ຮູບ Krogan ຖ່າຍຈາກ ສິລະປະ Deviant ໂດຍ​ການ​ອະ​ນຸ​ຍາດ​ຂອງ​ຜູ້​ຂຽນ​:

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