ກຸ່ມຄົນລົ້ມເຫລວ PostgreSQL + Patroni. ປະສົບການການຈັດຕັ້ງປະຕິບັດ

ໃນບົດຄວາມນີ້ຂ້າພະເຈົ້າຈະບອກທ່ານວ່າພວກເຮົາເຂົ້າຫາບັນຫາຄວາມຜິດຂອງ PostgreSQL, ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນຕໍ່ພວກເຮົາ, ແລະສິ່ງທີ່ເກີດຂຶ້ນໃນທີ່ສຸດ.

ພວກ​ເຮົາ​ມີ​ການ​ບໍ​ລິ​ການ​ທີ່​ມີ​ການ​ໂຫຼດ​ສູງ​: 2,5 ລ້ານ​ຜູ້​ຊົມ​ໃຊ້​ໃນ​ທົ່ວ​ໂລກ​, 50K+ ຜູ້​ໃຊ້​ການ​ເຄື່ອນ​ໄຫວ​ໃນ​ແຕ່​ລະ​ມື້​. ເຊີບເວີຕັ້ງຢູ່ໃນ Amazone ໃນເຂດຫນຶ່ງຂອງປະເທດໄອແລນ: 100+ ເຊີບເວີທີ່ແຕກຕ່າງກັນຢູ່ໃນການດໍາເນີນງານຢ່າງຕໍ່ເນື່ອງ, ເກືອບ 50 ຂອງພວກເຂົາມີຖານຂໍ້ມູນ.

backend ທັງຫມົດແມ່ນຄໍາຮ້ອງສະຫມັກ Java ທີ່ມີລັດ monolithic ຂະຫນາດໃຫຍ່ທີ່ຮັກສາການເຊື່ອມຕໍ່ websocket ຢ່າງຕໍ່ເນື່ອງກັບລູກຄ້າ. ເມື່ອຜູ້ໃຊ້ຫຼາຍຄົນເຮັດວຽກພ້ອມໆກັນຢູ່ໃນກະດານດຽວກັນ, ພວກເຂົາທັງຫມົດເຫັນການປ່ຽນແປງໃນເວລາທີ່ແທ້ຈິງ, ເພາະວ່າພວກເຮົາບັນທຶກທຸກໆການປ່ຽນແປງໃນຖານຂໍ້ມູນ. ພວກເຮົາມີການຮ້ອງຂໍປະມານ 10K ຕໍ່ວິນາທີຕໍ່ກັບຖານຂໍ້ມູນຂອງພວກເຮົາ. ໃນການໂຫຼດສູງສຸດໃນ Redis ພວກເຮົາຂຽນຄໍາຮ້ອງຂໍ 80-100K ຕໍ່ວິນາທີ.

ເປັນຫຍັງພວກເຮົາຈຶ່ງປ່ຽນຈາກ Redis ໄປ PostgreSQL

ໃນເບື້ອງຕົ້ນ, ການບໍລິການຂອງພວກເຮົາເຮັດວຽກກັບ Redis, ການເກັບຮັກສາທີ່ສໍາຄັນທີ່ເກັບຂໍ້ມູນທັງຫມົດໃນ RAM ຂອງເຄື່ອງແມ່ຂ່າຍ.

ຂໍ້ດີຂອງ Redis:

1. ຄວາມໄວຕອບສະຫນອງສູງ, ເພາະວ່າ ທຸກສິ່ງທຸກຢ່າງຖືກເກັບໄວ້ໃນຄວາມຊົງຈໍາ;
2. ການ​ສໍາ​ຮອງ​ສະ​ດວກ​ແລະ​ການ​ຈໍາ​ລອງ​.

ຂໍ້ເສຍຂອງ Redis ສໍາລັບພວກເຮົາ:

1. ບໍ່ມີທຸລະກໍາທີ່ແທ້ຈິງ. ພວກເຮົາພະຍາຍາມຮຽນແບບພວກເຂົາໃນລະດັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ແຕ່ຫນ້າເສຍດາຍ, ນີ້ບໍ່ໄດ້ຜົນດີສະເຫມີແລະຕ້ອງການການຂຽນລະຫັດທີ່ສັບສົນຫຼາຍ.
2. ຈໍານວນຂໍ້ມູນຖືກຈໍາກັດໂດຍຈໍານວນຫນ່ວຍຄວາມຈໍາ. ເມື່ອຈໍານວນຂໍ້ມູນເພີ່ມຂຶ້ນ, ຫນ່ວຍຄວາມຈໍາຈະເຕີບໂຕ, ແລະໃນທີ່ສຸດ, ພວກເຮົາຈະດໍາເນີນການເຂົ້າໄປໃນຄຸນລັກສະນະຂອງຕົວຢ່າງທີ່ເລືອກ, ເຊິ່ງໃນ AWS ຮຽກຮ້ອງໃຫ້ຢຸດເຊົາການບໍລິການຂອງພວກເຮົາເພື່ອປ່ຽນປະເພດຕົວຢ່າງ.
3. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຮັກສາລະດັບ latency ຕ່ໍາຢ່າງຕໍ່ເນື່ອງ, ເພາະວ່າ ພວກເຮົາມີຈໍານວນການຮ້ອງຂໍຫຼາຍ. ລະດັບ latency ທີ່ດີທີ່ສຸດສໍາລັບພວກເຮົາແມ່ນ 17-20 ms. ໃນລະດັບຂອງ 30-40 ms, ພວກເຮົາໄດ້ຮັບການຕອບສະຫນອງຍາວຕໍ່ກັບຄໍາຮ້ອງຂໍຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແລະການເຊື່ອມໂຊມການບໍລິການ. ແຕ່ຫນ້າເສຍດາຍ, ນີ້ເກີດຂຶ້ນກັບພວກເຮົາໃນເດືອນກັນຍາ 2018, ເມື່ອຫນຶ່ງໃນຕົວຢ່າງທີ່ມີ Redis ສໍາລັບເຫດຜົນບາງຢ່າງໄດ້ຮັບການ latency ທີ່ສູງກວ່າປົກກະຕິ 2 ເທົ່າ. ເພື່ອແກ້ໄຂບັນຫາ, ພວກເຮົາຢຸດເຊົາການບໍລິການໃນກາງວັນເຮັດວຽກສໍາລັບການບໍາລຸງຮັກສາທີ່ບໍ່ໄດ້ກໍານົດເວລາແລະປ່ຽນແທນຕົວຢ່າງ Redis ທີ່ມີບັນຫາ.
4. ມັນງ່າຍທີ່ຈະໄດ້ຮັບຂໍ້ມູນທີ່ບໍ່ສອດຄ່ອງເຖິງແມ່ນວ່າມີຂໍ້ຜິດພາດເລັກນ້ອຍໃນລະຫັດແລະຫຼັງຈາກນັ້ນໃຊ້ເວລາຫຼາຍໃນການຂຽນລະຫັດເພື່ອແກ້ໄຂຂໍ້ມູນນັ້ນ.

ພວກເຮົາໄດ້ພິຈາລະນາຂໍ້ເສຍແລະຮັບຮູ້ວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຍ້າຍໄປສູ່ສິ່ງທີ່ສະດວກກວ່າ, ດ້ວຍການເຮັດທຸລະກໍາແບບປົກກະຕິແລະການເພິ່ງພາອາໄສ latency ຫນ້ອຍລົງ. ພວກເຮົາໄດ້ເຮັດການຄົ້ນຄວ້າຂອງພວກເຮົາ, ວິເຄາະທາງເລືອກຫຼາຍຢ່າງແລະເລືອກ PostgreSQL.

ພວກເຮົາໄດ້ຍ້າຍໄປຫາຖານຂໍ້ມູນໃຫມ່ສໍາລັບ 1,5 ປີໃນປັດຈຸບັນແລະໄດ້ໂອນພຽງແຕ່ສ່ວນນ້ອຍໆຂອງຂໍ້ມູນ, ດັ່ງນັ້ນຕອນນີ້ພວກເຮົາກໍາລັງເຮັດວຽກພ້ອມໆກັນກັບ Redis ແລະ PostgreSQL. ຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບຂັ້ນຕອນຂອງການເຄື່ອນຍ້າຍແລະການປ່ຽນຂໍ້ມູນລະຫວ່າງຖານຂໍ້ມູນແມ່ນຂຽນໄວ້ໃນ ບົດຄວາມໂດຍເພື່ອນຮ່ວມງານຂອງຂ້ອຍ.

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

ການປະຕິບັດ PgBouncer

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

ພວກເຮົາມີສອງທາງເລືອກສໍາລັບຜູ້ຈັດການການເຊື່ອມຕໍ່: Pgpool ແລະ PgBouncer. ແຕ່ອັນທໍາອິດບໍ່ສະຫນັບສະຫນູນຮູບແບບການເຮັດທຸລະກໍາຂອງການເຮັດວຽກກັບຖານຂໍ້ມູນ, ດັ່ງນັ້ນພວກເຮົາໄດ້ເລືອກ PgBouncer.

ພວກເຮົາໄດ້ກໍານົດຮູບແບບການເຮັດວຽກຕໍ່ໄປນີ້: ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາເຂົ້າເຖິງຫນຶ່ງ PgBouncer, ທີ່ຢູ່ເບື້ອງຫຼັງມີແມ່ບົດ PostgreSQL, ແລະຢູ່ເບື້ອງຫຼັງແມ່ບົດແຕ່ລະຄົນມີຫນຶ່ງ replica ກັບການ replication asynchronous.


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

PgBouncer ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ

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

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

ພວກເຮົາສ້າງໂຄງການຄວາມທົນທານຄວາມຜິດ PgBouncer ດັ່ງຕໍ່ໄປນີ້: ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນທັງຫມົດເຂົ້າເຖິງ Network Load Balancer, ທີ່ຢູ່ເບື້ອງຫຼັງມີສອງ PgBouncers. ແຕ່ລະຄົນຂອງ PgBouncers ເບິ່ງ PostgreSQL ຕົ້ນສະບັບດຽວກັນຂອງແຕ່ລະ shard. ຖ້າສະຖານະການທີ່ມີຕົວຢ່າງຂອງ AWS ເກີດຂຶ້ນຊ້ຳ, ການຈະລາຈອນທັງຫມົດຈະຖືກໂອນຜ່ານ PgBouncer ອື່ນ. ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດຂອງ Network Load Balancer ແມ່ນສະໜອງໃຫ້ໂດຍ AWS.

ໂຄງການນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມເຄື່ອງແມ່ຂ່າຍ PgBouncer ໃໝ່ໄດ້ຢ່າງງ່າຍດາຍ.

ການສ້າງກຸ່ມ PostgreSQL Failover Cluster

ເມື່ອແກ້ໄຂບັນຫານີ້, ພວກເຮົາໄດ້ພິຈາລະນາທາງເລືອກທີ່ແຕກຕ່າງກັນ: ຄວາມລົ້ມເຫລວທີ່ຂຽນດ້ວຍຕົນເອງ, repmgr, AWS RDS, Patroni.

ສະຄຣິບທີ່ຂຽນດ້ວຍຕົນເອງ

ພວກເຂົາສາມາດຕິດຕາມການເຮັດວຽກຂອງແມ່ບົດແລະ, ຖ້າມັນລົ້ມເຫລວ, ສົ່ງເສີມການຈໍາລອງກັບແມ່ບົດແລະປັບປຸງການຕັ້ງຄ່າ PgBouncer.

ຂໍ້ດີຂອງວິທີການນີ້ແມ່ນຄວາມງ່າຍດາຍສູງສຸດ, ເພາະວ່າທ່ານຂຽນສະຄິບດ້ວຍຕົນເອງແລະເຂົ້າໃຈຢ່າງແນ່ນອນວ່າພວກມັນເຮັດວຽກແນວໃດ.

Cons:

• ແມ່ບົດອາດຈະບໍ່ຕາຍ; ແທນທີ່ຈະ, ມັນອາດຈະມີຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍ. ຄວາມລົ້ມເຫຼວ, ບໍ່ຮູ້ເລື່ອງນີ້, ຈະສົ່ງເສີມການຈໍາລອງກັບແມ່ບົດ, ແລະຕົ້ນສະບັບເກົ່າຈະສືບຕໍ່ເຮັດວຽກ. ດັ່ງນັ້ນ, ພວກເຮົາຈະໄດ້ຮັບສອງເຄື່ອງແມ່ຂ່າຍໃນບົດບາດແມ່ບົດແລະຈະບໍ່ຮູ້ວ່າພວກເຂົາໃດມີຂໍ້ມູນຫຼ້າສຸດໃນປະຈຸບັນ. ສະຖານະການນີ້ຍັງເອີ້ນວ່າການແບ່ງປັນສະຫມອງ;
• ພວກເຮົາຖືກປະໄວ້ໂດຍບໍ່ມີການຕອບສະຫນອງ. ໃນການຕັ້ງຄ່າຂອງພວກເຮົາມີຕົ້ນສະບັບແລະຫນຶ່ງ replica, ຫຼັງຈາກທີ່ປ່ຽນ replica ໄດ້ຖືກສົ່ງເສີມເປັນຕົ້ນສະບັບແລະພວກເຮົາບໍ່ມີ replicas ຕໍ່ໄປອີກແລ້ວ, ດັ່ງນັ້ນພວກເຮົາຕ້ອງເພີ່ມ replica ໃຫມ່ດ້ວຍຕົນເອງ;
• ພວກເຮົາຕ້ອງການການຕິດຕາມການປະຕິບັດການລົ້ມເຫຼວເພີ່ມເຕີມ, ແລະພວກເຮົາມີ 12 PostgreSQL shards, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕິດຕາມກວດກາ 12 ກຸ່ມ. ເມື່ອເພີ່ມຈໍານວນຂອງ shards, ທ່ານຍັງຕ້ອງຈື່ຈໍາທີ່ຈະປັບປຸງການລົ້ມເຫຼວ.

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

Repmgr

Replication Manager ສໍາລັບກຸ່ມ PostgreSQL, ເຊິ່ງສາມາດຈັດການການເຮັດວຽກຂອງກຸ່ມ PostgreSQL. ໃນເວລາດຽວກັນ, ມັນບໍ່ມີຄວາມຜິດພາດອັດຕະໂນມັດອອກຈາກກ່ອງ, ດັ່ງນັ້ນເພື່ອເຮັດວຽກທ່ານຈໍາເປັນຕ້ອງຂຽນ "wrapper" ຂອງທ່ານເອງຢູ່ເທິງສຸດຂອງການແກ້ໄຂທີ່ກຽມພ້ອມ. ດັ່ງນັ້ນ, ທຸກສິ່ງທຸກຢ່າງອາດຈະສັບສົນຫຼາຍກ່ວາກັບ script ທີ່ຂຽນດ້ວຍຕົນເອງ, ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາບໍ່ໄດ້ພະຍາຍາມ Repmgr.

AWS RDS

ມັນ​ສະ​ຫນັບ​ສະ​ຫນູນ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ພວກ​ເຮົາ​ຕ້ອງ​ການ​, ສາ​ມາດ​ເຮັດ​ໃຫ້​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ແລະ​ສະ​ຫນັບ​ສະ​ຫນູນ​ສະ​ນຸກ​ເກີ​ຂອງ​ການ​ເຊື່ອມ​ຕໍ່​. ມັນມີການປ່ຽນອັດຕະໂນມັດ: ເມື່ອແມ່ບົດເສຍຊີວິດ, replica ກາຍເປັນແມ່ບົດໃຫມ່, ແລະ AWS ປ່ຽນບັນທຶກ DNS ກັບແມ່ບົດໃຫມ່, ໃນຂະນະທີ່ replicas ສາມາດຕັ້ງຢູ່ໃນ AZs ທີ່ແຕກຕ່າງກັນ.

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

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

ນອກຈາກນັ້ນ, AWS RDS ແມ່ນເກືອບສອງເທົ່າຂອງລາຄາຕົວຢ່າງປົກກະຕິ, ເຊິ່ງເປັນເຫດຜົນຕົ້ນຕໍສໍາລັບການປະຖິ້ມການແກ້ໄຂນີ້.

Patroni

ນີ້ແມ່ນແມ່ແບບ python ສໍາລັບການຄຸ້ມຄອງ PostgreSQL ທີ່ມີເອກະສານທີ່ດີ, ການລົ້ມເຫລວອັດຕະໂນມັດແລະລະຫັດແຫຼ່ງໃນ github.

ຂໍ້​ດີ​ຂອງ Patroni​:

• ແຕ່ລະຕົວກໍານົດການກໍາຫນົດຄ່າໄດ້ຖືກອະທິບາຍ, ມັນເປັນທີ່ຊັດເຈນວ່າມັນເຮັດວຽກແນວໃດ;
• ອັດຕະໂນມັດລົ້ມເຫລວເຮັດວຽກອອກຈາກກ່ອງ;
• ຂຽນໃນ python, ແລະນັບຕັ້ງແຕ່ຕົວເຮົາເອງຂຽນຫຼາຍໃນ python, ມັນຈະງ່າຍຂຶ້ນສໍາລັບພວກເຮົາທີ່ຈະຈັດການກັບບັນຫາແລະ, ບາງທີ, ແມ້ກະທັ້ງຊ່ວຍພັດທະນາໂຄງການ;
• ຄວບຄຸມ PostgreSQL ຢ່າງເຕັມສ່ວນ, ຊ່ວຍໃຫ້ທ່ານສາມາດປ່ຽນການຕັ້ງຄ່າໃນທຸກ nodes ຂອງ cluster ໃນເວລາດຽວກັນ, ແລະຖ້າການນໍາໃຊ້ການຕັ້ງຄ່າໃຫມ່ຮຽກຮ້ອງໃຫ້ມີການເລີ່ມຕົ້ນຂອງ cluster, ນີ້ສາມາດເຮັດໄດ້ອີກເທື່ອຫນຶ່ງໂດຍໃຊ້ Patroni.

Cons:

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

ດັ່ງນັ້ນ, ພວກເຮົາເລືອກ Patroni ເພື່ອສ້າງກຸ່ມທີ່ລົ້ມເຫລວ.

ຂະບວນການປະຕິບັດ Patroni

ກ່ອນ Patroni, ພວກເຮົາມີ 12 PostgreSQL shards ໃນຫນຶ່ງຕົ້ນສະບັບແລະຫນຶ່ງ replica configuration ກັບ asynchronous replication. ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນໄດ້ເຂົ້າເຖິງຖານຂໍ້ມູນໂດຍຜ່ານ Network Load Balancer, ທີ່ຢູ່ເບື້ອງຫຼັງມີສອງຕົວຢ່າງທີ່ມີ PgBouncer, ແລະຢູ່ເບື້ອງຫຼັງແມ່ນເຄື່ອງແມ່ຂ່າຍ PostgreSQL ທັງຫມົດ.


ເພື່ອປະຕິບັດ Patroni, ພວກເຮົາຈໍາເປັນຕ້ອງເລືອກບ່ອນເກັບຂໍ້ມູນການຕັ້ງຄ່າກຸ່ມທີ່ແຈກຢາຍ. Patroni ເຮັດວຽກກັບລະບົບການເກັບຮັກສາການຕັ້ງຄ່າທີ່ແຈກຢາຍເຊັ່ນ: etcd, Zookeeper, Consul. ພວກເຮົາມີກຸ່ມ Consul ເຕັມຮູບແບບໃນການຜະລິດ, ເຊິ່ງເຮັດວຽກຮ່ວມກັນກັບ Vault ແລະພວກເຮົາບໍ່ໄດ້ໃຊ້ມັນອີກຕໍ່ໄປ. ເຫດຜົນທີ່ຍິ່ງໃຫຍ່ເພື່ອເລີ່ມຕົ້ນການນໍາໃຊ້ Consul ສໍາລັບຈຸດປະສົງຂອງຕົນ.

Patroni ເຮັດວຽກແນວໃດກັບກົງສຸນ

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

ເພື່ອເຊື່ອມຕໍ່ Patroni ກັບ Consul, ພຽງແຕ່ສຶກສາເອກະສານທາງການ, ເຊິ່ງບອກວ່າທ່ານຕ້ອງການກໍານົດເຈົ້າພາບໃນຮູບແບບ http ຫຼື https, ຂຶ້ນກັບວິທີທີ່ພວກເຮົາເຮັດວຽກກັບ Consul, ແລະແຜນວາດການເຊື່ອມຕໍ່, ທາງເລືອກ:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

ມັນເບິ່ງງ່າຍດາຍ, ແຕ່ນີ້ແມ່ນບ່ອນທີ່ pitfalls ເລີ່ມຕົ້ນ. ກັບ Consul ພວກເຮົາເຮັດວຽກຜ່ານການເຊື່ອມຕໍ່ທີ່ປອດໄພຜ່ານ https ແລະການຕັ້ງຄ່າການເຊື່ອມຕໍ່ຂອງພວກເຮົາຈະມີລັກສະນະນີ້:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

ແຕ່ມັນບໍ່ເຮັດວຽກແບບນັ້ນ. ໃນຕອນເລີ່ມຕົ້ນ, Patroni ບໍ່ສາມາດເຊື່ອມຕໍ່ກັບ Consul ໄດ້ເພາະວ່າມັນຍັງພະຍາຍາມຜ່ານ http.

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Consul-ແມ່ແບບ

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

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

ມັນໄດ້ຫັນອອກວ່າ Consul-template ຕິດຕາມການຕັ້ງຄ່າຂອງກຸ່ມ PostgreSQL ຢູ່ກົງສຸນຢ່າງຕໍ່ເນື່ອງ. ເມື່ອຜູ້ນໍາປ່ຽນແປງ, ມັນປັບປຸງການຕັ້ງຄ່າ PgBouncer ແລະສົ່ງຄໍາສັ່ງເພື່ອໂຫລດມັນໃຫມ່.

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

ສະຖາປັດຕະຍະກໍາໃຫມ່ກັບ Patroni

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບໂຄງການເຮັດວຽກດັ່ງຕໍ່ໄປນີ້:


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

ການທົດສອບດ້ວຍມື

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

ສະຕິກເກີກັບຄືນມາພາຍໃນ 10-20 ວິນາທີ, ແລະຫຼັງຈາກນັ້ນເລີ່ມເຄື່ອນທີ່ເປັນປົກກະຕິອີກເທື່ອຫນຶ່ງ. ນີ້ຫມາຍຄວາມວ່າກຸ່ມ Patroni ເຮັດວຽກຢ່າງຖືກຕ້ອງ: ມັນປ່ຽນຜູ້ນໍາ, ສົ່ງຂໍ້ມູນໄປຫາ Consul, ແລະ Consul-templates ໄດ້ເອົາຂໍ້ມູນນີ້ທັນທີ, ປ່ຽນແທນການຕັ້ງຄ່າ PgBouncer ແລະສົ່ງຄໍາສັ່ງໃຫ້ໂຫຼດໃຫມ່.

ວິທີການຢູ່ລອດພາຍໃຕ້ການໂຫຼດສູງແລະຮັກສາເວລາຢຸດຫນ້ອຍທີ່ສຸດ?

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

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

ວຽກງານທັງສອງເບິ່ງມີຄວາມທະເຍີທະຍານ, ແຕ່ພວກເຮົາມີ PostgreSQL 9.6. ບາງທີພວກເຮົາສາມາດອັບເດດເປັນ 11.2 ໄດ້ທັນທີບໍ?

ພວກ​ເຮົາ​ຕັດ​ສິນ​ໃຈ​ທີ່​ຈະ​ເຮັດ​ແນວ​ນີ້​ໃນ 2 ຂັ້ນ​ຕອນ​: ຄັ້ງ​ທໍາ​ອິດ​ປັບ​ປຸງ​ສະ​ບັບ 11.2​, ຫຼັງ​ຈາກ​ນັ້ນ​ເປີດ Patroni​.

ອັບເດດ PostgreSQL

ເພື່ອປັບປຸງສະບັບ PostgreSQL ຢ່າງໄວວາ, ທ່ານຕ້ອງໃຊ້ທາງເລືອກ -k, ໃນທີ່ເຊື່ອມຕໍ່ຍາກແມ່ນຖືກສ້າງຂຶ້ນໃນແຜ່ນແລະບໍ່ຈໍາເປັນຕ້ອງຄັດລອກຂໍ້ມູນຂອງທ່ານ. ໃນຖານຂໍ້ມູນ 300-400 GB, ການປັບປຸງໃຊ້ເວລາ 1 ວິນາທີ.

ພວກເຮົາມີຫຼາຍ shards, ສະນັ້ນການປັບປຸງຈໍາເປັນຕ້ອງໄດ້ເຮັດອັດຕະໂນມັດ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໄດ້ຂຽນ Ansible playbook ທີ່ປະຕິບັດຂະບວນການປັບປຸງທັງຫມົດສໍາລັບພວກເຮົາ:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

ການເປີດຕົວຂອງ Patroni

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

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

rm -rf /var/lib/postgresql/

ອັນນີ້ຕ້ອງເຮັດແຕ່ຂ້າທາດເທົ່ານັ້ນ!

ໃນເວລາທີ່ເຊື່ອມຕໍ່ replica ທີ່ສະອາດ, Patroni ເຮັດໃຫ້ຜູ້ນໍາ basebackup ແລະຟື້ນຟູມັນກັບ replica, ແລະຫຼັງຈາກນັ້ນ catches up ກັບສະຖານະປະຈຸບັນໂດຍໃຊ້ wal logs.

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

ໂຫຼດການທົດສອບ

ພວກເຮົາໄດ້ເປີດຕົວການທົດສອບທີ່ຈໍາລອງວິທີທີ່ຜູ້ໃຊ້ເຮັດວຽກຢູ່ໃນກະດານ. ໃນເວລາທີ່ການໂຫຼດໄດ້ບັນລຸສະເລ່ຍປະຈໍາວັນຂອງພວກເຮົາ, ພວກເຮົາເຮັດຊ້ໍາການທົດສອບດຽວກັນຄືກັນອ້ອຍຕ້ອຍ, ພວກເຮົາໄດ້ປິດຫນຶ່ງຕົວຢ່າງທີ່ມີຜູ້ນໍາ PostgreSQL. ການລົ້ມເຫຼວອັດຕະໂນມັດເຮັດວຽກຕາມທີ່ພວກເຮົາຄາດໄວ້: Patroni ປ່ຽນຜູ້ນໍາ, Consul-template ປັບປຸງການຕັ້ງຄ່າ PgBouncer ແລະສົ່ງຄໍາສັ່ງໃຫ້ໂຫຼດໃຫມ່. ອີງຕາມກາຟຂອງພວກເຮົາໃນ Grafana, ມັນເປັນທີ່ຊັດເຈນວ່າມີຄວາມລ່າຊ້າ 20-30 ວິນາທີແລະຈໍານວນຂໍ້ຜິດພາດເລັກນ້ອຍຈາກເຄື່ອງແມ່ຂ່າຍທີ່ກ່ຽວຂ້ອງກັບການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ. ນີ້ແມ່ນສະຖານະການປົກກະຕິ, ຄຸນຄ່າດັ່ງກ່າວເປັນທີ່ຍອມຮັບໄດ້ສໍາລັບຄວາມລົ້ມເຫລວຂອງພວກເຮົາແລະແນ່ນອນດີກ່ວາເວລາຢຸດການບໍລິການ.

ການເປີດຕົວຂອງ Patroni ເຂົ້າໄປໃນການຜະລິດ

ດັ່ງນັ້ນ, ພວກເຮົາຈຶ່ງມີແຜນການດັ່ງນີ້:

• Deploy Consul-template ກັບເຊີບເວີ PgBouncer ແລະເປີດຕົວ;
• PostgreSQL ອັບເດດເປັນເວີຊັ່ນ 11.2;
• ການປ່ຽນແປງຊື່ກຸ່ມ;
• ເປີດຕົວກຸ່ມ Patroni.

ໃນເວລາດຽວກັນ, ໂຄງການຂອງພວກເຮົາອະນຸຍາດໃຫ້ພວກເຮົາເຮັດຈຸດທໍາອິດເກືອບທຸກເວລາ; ພວກເຮົາສາມາດເອົາ PgBouncer ແຕ່ລະຄົນອອກຈາກວຽກຫນຶ່ງຄັ້ງແລະປະຕິບັດການຈັດຕັ້ງປະຕິບັດແລະເປີດຕົວ consul-templates. ນັ້ນແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ເຮັດ.

ສໍາລັບການທົດສອບຢ່າງໄວວາ, ພວກເຮົາໄດ້ໃຊ້ Ansible, ເພາະວ່າພວກເຮົາໄດ້ທົດສອບປື້ມຫຼິ້ນທັງຫມົດໃນສະພາບແວດລ້ອມການທົດສອບແລ້ວ, ແລະເວລາປະຕິບັດສໍາລັບສະຄິບເຕັມແມ່ນຈາກ 1,5 ຫາ 2 ນາທີສໍາລັບແຕ່ລະ shard. ພວກເຮົາສາມາດມ້ວນອອກທຸກສິ່ງທຸກຢ່າງຫນຶ່ງຄັ້ງຕໍ່ແຕ່ລະ shard ໂດຍບໍ່ມີການຢຸດການບໍລິການຂອງພວກເຮົາ, ແຕ່ພວກເຮົາຈະຕ້ອງປິດ PostgreSQL ແຕ່ລະຄົນເປັນເວລາຫຼາຍນາທີ. ໃນ​ກໍ​ລະ​ນີ​ນີ້, ຜູ້​ໃຊ້​ທີ່​ມີ​ຂໍ້​ມູນ​ຢູ່​ໃນ shard ນີ້​ຈະ​ບໍ່​ສາ​ມາດ​ເຮັດ​ວຽກ​ຢ່າງ​ເຕັມ​ທີ່​ໃນ​ເວ​ລາ​ນີ້, ແລະ​ນີ້​ແມ່ນ​ບໍ່​ສາ​ມາດ​ຍອມ​ຮັບ​ສໍາ​ລັບ​ພວກ​ເຮົາ.

ວິທີການອອກຈາກສະຖານະການນີ້ແມ່ນການວາງແຜນການບໍາລຸງຮັກສາ, ເຊິ່ງພວກເຮົາເຮັດທຸກໆ 3 ເດືອນ. ນີ້ແມ່ນປ່ອງຢ້ຽມສໍາລັບການເຮັດວຽກທີ່ກໍານົດໄວ້, ເມື່ອພວກເຮົາປິດການບໍລິການຂອງພວກເຮົາຢ່າງສົມບູນແລະປັບປຸງຖານຂໍ້ມູນຕົວຢ່າງ. ຍັງມີເວລາຫນຶ່ງອາທິດຈົນກ່ວາປ່ອງຢ້ຽມຕໍ່ໄປ, ແລະພວກເຮົາໄດ້ຕັດສິນໃຈພຽງແຕ່ລໍຖ້າແລະກະກຽມຕື່ມອີກ. ໃນລະຫວ່າງການລໍຖ້າ, ພວກເຮົາຍັງໄດ້ປ້ອງກັນການວາງເດີມພັນຂອງພວກເຮົາ: ສໍາລັບແຕ່ລະ PostgreSQL shard ພວກເຮົາໄດ້ຍົກເອົາການຈໍາລອງແບບ spare ໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວ, ເພື່ອບັນທຶກຂໍ້ມູນຫລ້າສຸດ, ແລະເພີ່ມຕົວຢ່າງໃຫມ່ສໍາລັບແຕ່ລະ shard, ເຊິ່ງຄວນຈະກາຍເປັນ replica ໃຫມ່ໃນ Patroni. cluster, ເພື່ອບໍ່ໃຫ້ອອກຄໍາສັ່ງລຶບຂໍ້ມູນ . ທັງຫມົດນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງຄວາມຜິດພາດ.


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


ເປັນຫຍັງພວກເຮົາບໍ່ເຫັນສິ່ງນີ້ໃນສະພາບແວດລ້ອມການທົດສອບ? ບັນຫານີ້ສະແດງໃຫ້ເຫັນເຖິງຄວາມຈໍາເປັນທີ່ຈະຕ້ອງປະຕິບັດຕາມໂຄງສ້າງພື້ນຖານເປັນຫຼັກການລະຫັດແລະປັບປຸງໂຄງສ້າງພື້ນຖານທັງຫມົດ, ຈາກສະພາບແວດລ້ອມການທົດສອບຈົນເຖິງການຜະລິດ. ຖ້າບໍ່ດັ່ງນັ້ນ, ມັນງ່າຍຫຼາຍທີ່ຈະເອົາບັນຫາທີ່ພວກເຮົາໄດ້ຮັບ. ເກີດ​ຫຍັງ​ຂຶ້ນ? ກົງສຸນປະກົດຕົວຄັ້ງທໍາອິດໃນການຜະລິດ, ແລະຫຼັງຈາກນັ້ນໃນສະພາບແວດລ້ອມການທົດສອບ; ດັ່ງນັ້ນ, ໃນສະພາບແວດລ້ອມການທົດສອບສະບັບຂອງ Consul ແມ່ນສູງກວ່າການຜະລິດ. ພຽງແຕ່ໃນການປ່ອຍຫນຶ່ງ, CPU ຮົ່ວໄຫຼໃນເວລາທີ່ເຮັດວຽກກັບ consul-templates ໄດ້ຖືກແກ້ໄຂ. ດັ່ງນັ້ນພວກເຮົາພຽງແຕ່ປັບປຸງກົງສຸນ, ດັ່ງນັ້ນການແກ້ໄຂບັນຫາ.

ຣີສະຕາດກຸ່ມ Patroni

ຢ່າງໃດກໍຕາມ, ພວກເຮົາໄດ້ຮັບບັນຫາໃຫມ່ທີ່ພວກເຮົາບໍ່ໄດ້ສົງໃສວ່າ. ເມື່ອອັບເດດ Consul, ພວກເຮົາພຽງແຕ່ເອົາ Consul node ອອກຈາກ cluster ໂດຍໃຊ້ຄໍາສັ່ງ consul leave → Patroni ເຊື່ອມຕໍ່ກັບ Consul server ອື່ນ → ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ. ແຕ່ເມື່ອພວກເຮົາມາຮອດຕົວຢ່າງສຸດທ້າຍຂອງກຸ່ມກົງສຸນແລະສົ່ງມັນອອກຄໍາສັ່ງຈາກກົງສຸນ, ກຸ່ມ Patroni ທັງຫມົດພຽງແຕ່ເລີ່ມຕົ້ນໃຫມ່, ແລະໃນບັນທຶກທີ່ພວກເຮົາເຫັນຂໍ້ຜິດພາດຕໍ່ໄປນີ້:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

ກຸ່ມ Patroni ບໍ່ສາມາດໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບກຸ່ມຂອງມັນ ແລະປິດເປີດຄືນໃໝ່.

ເພື່ອຊອກຫາວິທີແກ້ໄຂ, ພວກເຮົາໄດ້ຕິດຕໍ່ກັບຜູ້ຂຽນຂອງ Patroni ຜ່ານບັນຫາໃນ github. ພວກເຂົາເຈົ້າໄດ້ແນະນໍາການປັບປຸງໄຟລ໌ການຕັ້ງຄ່າຂອງພວກເຮົາ:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

ພວກ​ເຮົາ​ສາ​ມາດ​ເຮັດ​ເລ​ື້ມ​ຄືນ​ບັນ​ຫາ​ໃນ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ທົດ​ສອບ​ແລະ​ການ​ທົດ​ສອບ​ການ​ຕັ້ງ​ຄ່າ​ເຫຼົ່າ​ນີ້​ມີ​, ແຕ່​ຫນ້າ​ເສຍ​ດາຍ​ພວກ​ເຂົາ​ບໍ່​ໄດ້​ເຮັດ​ວຽກ​.

ບັນຫາຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂ. ພວກເຮົາວາງແຜນທີ່ຈະພະຍາຍາມແກ້ໄຂຕໍ່ໄປນີ້:

• ໃຊ້ Consul-agent ໃນແຕ່ລະຕົວຢ່າງຂອງກຸ່ມ Patroni;
• ແກ້ໄຂບັນຫາໃນລະຫັດ.

ພວກເຮົາເຂົ້າໃຈບ່ອນທີ່ຂໍ້ຜິດພາດເກີດຂຶ້ນ: ອາດຈະເປັນບັນຫາໃນການນໍາໃຊ້ການຫມົດເວລາເລີ່ມຕົ້ນ, ເຊິ່ງບໍ່ໄດ້ຖືກ overridden ຜ່ານໄຟລ໌ການຕັ້ງຄ່າ. ເມື່ອເຊີບເວີ Consul ສຸດທ້າຍຖືກເອົາອອກຈາກກຸ່ມ, ກຸ່ມ Consul ທັງໝົດຈະຄ້າງ, ເຊິ່ງໃຊ້ເວລາດົນກວ່າໜຶ່ງວິນາທີ; ດ້ວຍເຫດນີ້, Patroni ບໍ່ສາມາດໄດ້ຮັບສະຖານະຂອງກຸ່ມ ແລະ ຣີສະຕາດກຸ່ມທັງໝົດທັງໝົດ.

ໂຊກດີ, ພວກເຮົາບໍ່ໄດ້ພົບຂໍ້ຜິດພາດອີກຕໍ່ໄປ.

ຜົນໄດ້ຮັບຂອງການນໍາໃຊ້ Patroni

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


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

ບົດສະຫຼຸບສັ້ນໆຂອງການໃຊ້ Patroni:

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

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