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

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

ເປັນຫຍັງຂ້ອຍຈຶ່ງຕ້ອງການມັນ?

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

ພົບກັບການປະນີປະນອມ

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

Tradeoff 1: ການປະຕິບັດ

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

Tradeoff 2: ຄວາມສອດຄ່ອງ

ຜົນໄດ້ຮັບໃນກໍລະນີຂອງຄວາມລົ້ມເຫຼວຂອງຜູ້ນໍາໃນສອງວິທີການເຫຼົ່ານີ້ຍັງຈະແຕກຕ່າງກັນ. ຖ້າການເຮັດວຽກຖືກປະຕິບັດບໍ່ກົງກັນ, ຫຼັງຈາກນັ້ນ, ຖ້າຂໍ້ຜິດພາດດັ່ງກ່າວເກີດຂື້ນ, ບໍ່ແມ່ນບັນທຶກທັງຫມົດຈະຖືກເຮັດໂດຍ replicas. ຈະເສຍເທົ່າໃດ? ຂຶ້ນກັບຄໍາຮ້ອງສະຫມັກຕົວມັນເອງແລະປະສິດທິພາບຂອງການຈໍາລອງ. Compose replication ຈະປ້ອງກັນບໍ່ໃຫ້ replica ຈາກການກາຍເປັນຜູ້ນໍາຖ້າຫາກວ່າຈໍານວນຂໍ້ມູນໃນມັນແມ່ນ 1 MB ຫນ້ອຍກ່ວາຜູ້ນໍາ, ນັ້ນແມ່ນ, ເຖິງ 1 MB ຂອງບັນທຶກອາດຈະສູນເສຍໄປໃນລະຫວ່າງການປະຕິບັດງານ asynchronous.

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

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

Trade-off 3: ການຂັດຂ້ອງ

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

ການເຊື່ອມຕໍ່ຫນຶ່ງຕໍ່ທຸລະກໍາ?

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

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

ຮັບປະກັນການຄວບຄຸມໃນການປະຕິບັດ

ໂດຍຄ່າເລີ່ມຕົ້ນ, PostgreSQL ສະຫນອງຄວາມສອດຄ່ອງ. ອັນນີ້ຖືກຄວບຄຸມໂດຍພາລາມິເຕີເຊີບເວີ synchronous_commit. ໂດຍຄ່າເລີ່ມຕົ້ນມັນຢູ່ໃນຕໍາແຫນ່ງ on, ແຕ່​ວ່າ​ມັນ​ມີ​ສາມ​ທາງ​ເລືອກ​ອື່ນ​: local, remote_write ຫຼື off.

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

ໂດຍການພິຈາລະນາທາງເລືອກທີ່ມີຢູ່, ພວກເຮົາເລືອກພຶດຕິກໍາແລະ, ຈື່ໄວ້ວ່າ on – ເຫຼົ່ານີ້ແມ່ນການບັນທຶກ synchronous, ພວກເຮົາຈະເລືອກເອົາ local ສໍາລັບ asynchronous commits ໃນໄລຍະເຄືອຂ່າຍ, ໃນຂະນະທີ່ອອກຈາກທ້ອງຖິ່ນ commits synchronous.

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

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

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

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

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

ການຕັ້ງຄ່າ PostgreSQL

ກ່ອນນີ້, ພວກເຮົາຈິນຕະນາການລະບົບ PostgreSQL ກັບ synchronous_commit, ຕິດ​ຕັ້ງ​ໃນ​ local. ເພື່ອເຮັດໃຫ້ຄວາມເປັນຈິງໃນດ້ານເຊີຟເວີ, ທ່ານຈະຕ້ອງກໍານົດສອງທາງເລືອກໃນການຕັ້ງຄ່າຂອງເຄື່ອງແມ່ຂ່າຍ. ຕົວກໍານົດການເພີ່ມເຕີມ synchronous_standby_names ຈະເຂົ້າມາໃນຕົວຂອງມັນເອງເມື່ອໃດ synchronous_commit ຈະຢູ່ໃນ on. ມັນກໍານົດວ່າ replicas ໃດທີ່ມີສິດໄດ້ຮັບສໍາລັບ synchronous commits, ແລະພວກເຮົາຈະຕັ້ງມັນເປັນ. *, ເຊິ່ງຈະຫມາຍຄວາມວ່າ replicas ທັງຫມົດມີສ່ວນຮ່ວມ. ຄ່າເຫຼົ່ານີ້ແມ່ນປົກກະຕິແລ້ວ configured ໃນ ໄຟລ໌ການຕັ້ງຄ່າ ໂດຍການເພີ່ມ:

synchronous_commit = local  
synchronous_standby_names='*'

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

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

ອີກສອງສາມຄຳ...

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

ການຕັ້ງຄ່ານີ້ສາມາດປ່ຽນແປງໄດ້ທຸກເວລາ. ພຶດຕິກໍາສໍາລັບທຸລະກໍາໃດຫນຶ່ງແມ່ນຖືກກໍານົດໂດຍການຕັ້ງຄ່າທີ່ມີຜົນໃນເວລາທີ່ຄໍາຫມັ້ນສັນຍາ. ດັ່ງນັ້ນ, ມັນເປັນໄປໄດ້ແລະເປັນປະໂຫຍດສໍາລັບການເຮັດທຸລະກໍາບາງຢ່າງທີ່ຈະປະຕິບັດ synchronously ແລະສໍາລັບຄົນອື່ນ asynchronously. ສໍາລັບຕົວຢ່າງ, ບັງຄັບຫນຶ່ງ multistatement ທຸລະກໍາເພື່ອເຮັດໃຫ້ຄໍາຫມັ້ນສັນຍາ asynchronously ເມື່ອຄ່າເລີ່ມຕົ້ນຂອງພາລາມິເຕີກົງກັນຂ້າມ, ຕັ້ງ SET LOCAL synchronous_commit TO OFF ໃນທຸລະກໍາ.

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

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