🥇 "Pro, ແຕ່ບໍ່ແມ່ນກຸ່ມ" ຫຼືວິທີທີ່ພວກເຮົາປ່ຽນແທນການນໍາເຂົ້າ DBMS

(ts) Yandex.Images

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

ພວກເຮົາມີປະສົບການຢ່າງຫຼວງຫຼາຍໃນການໂອນລະບົບຂໍ້ມູນທີ່ມີເຫດຜົນເຂົ້າໄປໃນຖານຂໍ້ມູນຈາກ DBMS ຫນຶ່ງໄປຫາອີກ. ໃນສະພາບການຂອງລັດຖະດໍາລັດສະບັບເລກທີ 1236 ຂອງເດືອນພະຈິກ 16.11.2016, XNUMX, ນີ້ມັກຈະເປັນການໂອນຈາກ Oracle ໄປ Postgresql. ພວກເຮົາສາມາດບອກທ່ານແຍກຕ່າງຫາກກ່ຽວກັບວິທີການຈັດຕັ້ງຂະບວນການທີ່ມີປະສິດທິພາບແລະບໍ່ເຈັບປວດເທົ່າທີ່ເປັນໄປໄດ້;

Spoiler – ແມ່ນ, cap, RAC ແລະ pg multimaster ແມ່ນການແກ້ໄຂທີ່ແຕກຕ່າງກັນຫຼາຍ.

ໃຫ້ເວົ້າວ່າທ່ານໄດ້ໂອນເຫດຜົນທັງຫມົດຈາກ plsql ໄປ pgsql ແລ້ວ. ແລະການທົດສອບການຖົດຖອຍຂອງເຈົ້າແມ່ນຂ້ອນຂ້າງດີ, ແນ່ນອນວ່າເຈົ້າກໍາລັງຄິດກ່ຽວກັບການປັບຂະຫນາດ, ເພາະວ່າ ... ການທົດສອບການໂຫຼດບໍ່ໄດ້ເຮັດໃຫ້ທ່ານມີຄວາມສຸກຫຼາຍ, ໂດຍສະເພາະໃນຮາດແວທີ່ລວມຢູ່ໃນໂຄງການໃນເບື້ອງຕົ້ນ, ສໍາລັບ DBMS ທີ່ແຕກຕ່າງກັນຫຼາຍ. ໃຫ້ເວົ້າວ່າທ່ານພົບການແກ້ໄຂຈາກຜູ້ຂາຍພາຍໃນປະເທດ "Postgres Professional" ທີ່ມີທາງເລືອກທີ່ເອີ້ນວ່າ "multimaster", ເຊິ່ງມີຢູ່ໃນສະບັບ "ສູງສຸດ" ຂອງ "Postgres Pro Enterprise" ແລະອີງຕາມຄໍາອະທິບາຍ - ມັນຄ້າຍຄືກັນກັບສິ່ງທີ່. ທ່ານຕ້ອງການ, ແລະດ້ວຍການສຶກສາແບບພິເສດຄັ້ງທໍາອິດ, ມັນຈະເກີດຄວາມຄິດເຂົ້າມາໃນຫົວຂອງຂ້ອຍ: "ໂອ້! ແທນທີ່ຈະ RAC, ນັ້ນແມ່ນມັນ! ແລະເຖິງແມ່ນວ່າມີທໍ່ທາງວິຊາການຢູ່ໃນບ້ານເກີດເມືອງນອນຂອງພວກເຮົາ!”

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

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

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

ເກີດຄວາມຜິດພາດຂຶ້ນ:

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

ຫຼັງຈາກນັ້ນ, ທ່ານສາມາດຕໍ່ສູ້ເປັນເວລາດົນນານກັບ lock ຕາຍໃນຮຸ່ນ 10.5, 10.6, ແລະການແກ້ໄຂທີ່ຮູ້ຈັກດຽວທີ່ຂ້າຄວາມສໍາຄັນທັງຫມົດຂອງກຸ່ມແມ່ນເພື່ອເອົາຕາຕະລາງ "ບັນຫາ" ອອກຈາກກຸ່ມ, i.e. ເຮັດ make_table_local, ແຕ່ນີ້ຢ່າງຫນ້ອຍຈະອະນຸຍາດໃຫ້ມັນເຮັດວຽກ, ແລະຈະບໍ່ເຮັດໃຫ້ທຸກສິ່ງທຸກຢ່າງຖືກລະງັບເນື່ອງຈາກການຫ້ອຍລໍຖ້າສໍາລັບທຸລະກໍາ commits. ດີ, ຫຼືຕິດຕັ້ງການອັບເດດເປັນເວີຊັນ 11.2, ເຊິ່ງຄວນຊ່ວຍ, ແຕ່ອາດຈະບໍ່, ຢ່າລືມກວດເບິ່ງ.

ໃນບາງສະບັບ, ທ່ານສາມາດໄດ້ຮັບລັອກທີ່ລຶກລັບກວ່າ:

username= mtm и backend_type = background worker

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

ການປະຕິບັດງານບາງຢ່າງທີ່ມີດັດສະນີສາມາດນໍາໄປສູ່ຄວາມຜິດພາດ, ເຊິ່ງຊີ້ໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າບັນຫາແມ່ນຢູ່ໃນການຈໍາລອງແບບ Bi-Directional ທ່ານຈະເຫັນ BDR ໂດຍກົງໃນບັນທຶກ MTM. ມັນແມ່ນ 2nd Quadrant ແທ້ໆບໍ? ບໍ່ ... ພວກເຮົາໄດ້ຊື້ multimaster, ມັນເປັນພຽງແຕ່ຄວາມບັງເອີນ, ມັນເປັນຊື່ຂອງເຕັກໂນໂລຢີ.

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448

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

ຫຼັງຈາກນັ້ນ, ໃນຄວາມເປັນຈິງ, ທ່ານຈະໄດ້ຮັບການຈໍາລອງແບບນັ້ນບໍ່ໄດ້ເຮັດວຽກທົ່ວທຸກຕາຕະລາງທີ່ໃຊ້ໃນຂັ້ນຕອນ, ຖ້າລະຫັດປະກອບດ້ວຍການສ້າງຕາຕະລາງຊົ່ວຄາວ, ແລະເຖິງແມ່ນວ່າການນໍາໃຊ້ multimaster.remote_functions ຈະບໍ່ຊ່ວຍ, ທ່ານຈະຕ້ອງປັບປຸງຫຼືຂຽນຄືນໃຫມ່ຕາມເຫດຜົນຂອງທ່ານ. ຂັ້ນຕອນການ. ຖ້າຫາກວ່າທ່ານຕ້ອງການນໍາໃຊ້ສອງຂະຫຍາຍ multimaster ແລະ pg_pathman ພ້ອມກັນພາຍໃນຂອບເຂດຂອງ "Postgres Pro Enterprise" v 10.5, ໃຫ້ກວດເບິ່ງວ່າດ້ວຍຕົວຢ່າງງ່າຍດາຍນີ້:

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

ຂໍ້ຜິດພາດຕໍ່ໄປນີ້ເລີ່ມປາກົດຢູ່ໃນບັນທຶກໃນ DBMS nodes:

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

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

ຈະເຮັດແນວໃດ? ສິດ! ອັບເກຣດເປັນ "Postgres Pro Enterprise" v 11.2

ແຍກຕ່າງຫາກ, ທ່ານຈໍາເປັນຕ້ອງຮູ້ວ່າລໍາດັບນັ້ນ, ເປັນວັດຖຸຂອງຖານຂໍ້ມູນທີ່ເຮັດຊ້ໍາກັນ, ບໍ່ມີຄ່າ end-to-end ໃນທົ່ວ cluster, ແຕ່ລະລໍາດັບແມ່ນທ້ອງຖິ່ນສໍາລັບແຕ່ລະ node ແລະຖ້າຫາກວ່າທ່ານມີພາກສະຫນາມທີ່ມີຂໍ້ຈໍາກັດເປັນເອກະລັກແລະລໍາດັບການນໍາໃຊ້, ຫຼັງຈາກນັ້ນ, ທ່ານພຽງແຕ່ສາມາດເຮັດໃຫ້ການເພີ່ມຂຶ້ນເທົ່າກັບຈໍານວນ node ໃນ cluster, ເພາະວ່າ ໃນຫຼາຍ nodes ໃນ cluster ເທົ່າທີ່ເປັນໄປໄດ້, sequence ແລະ int ຈະເຕີບໂຕໄວກວ່າທີ່ທ່ານຄາດໄວ້. ເພື່ອງ່າຍການເຮັດວຽກກັບລໍາດັບໃນຜະລິດຕະພັນ, ທ່ານຈະຊອກຫາຟັງຊັນ alter_sequences, ເຊິ່ງຈະເຮັດໃຫ້ການເພີ່ມຂຶ້ນທີ່ຈໍາເປັນສໍາລັບແຕ່ລະລໍາດັບໃນທຸກ nodes, ແຕ່ກຽມພ້ອມວ່າຟັງຊັນຈະບໍ່ເຮັດວຽກໃນທຸກຮຸ່ນ. ແນ່ນອນ, ທ່ານສາມາດຂຽນມັນດ້ວຍຕົນເອງ, ການນໍາໃຊ້ລະຫັດຈາກ github ເປັນພື້ນຖານຫຼືແກ້ໄຂມັນເອງໂດຍກົງໃນ DBMS. ໃນກໍລະນີນີ້, ທົ່ງນາທີ່ມີປະເພດ serialbigserial ຈະເຮັດວຽກຢ່າງຖືກຕ້ອງ, ແຕ່ເພື່ອນໍາໃຊ້ພວກມັນ, ສ່ວນຫຼາຍອາດຈະຈໍາເປັນຕ້ອງຂຽນລະຫັດຂອງຂັ້ນຕອນແລະຫນ້າທີ່ຂອງທ່ານ. ບາງທີບາງຄົນຈະຊອກຫາຫນ້າທີ່ monotonic_sequences ທີ່ເປັນປະໂຫຍດ.

ກ່ອນທີ່ຈະສະບັບ 11.2 ຂອງ Postgres Pro Enterprise, ການຈໍາລອງຈະເຮັດວຽກພຽງແຕ່ຖ້າມີລະຫັດຫຼັກທີ່ບໍ່ຊ້ໍາກັນ, ໃຫ້ຄໍານຶງເຖິງນີ້ໃນເວລາພັດທະນາ.

ແຍກຕ່າງຫາກ, ຂ້າພະເຈົ້າຢາກກ່າວເຖິງລັກສະນະພິເສດຂອງວິທີການ npgsql ເຮັດວຽກຢູ່ໃນການແກ້ໄຂກຸ່ມ;
ໃນບາງສະບັບທີ່ທ່ານອາດຈະພົບກັບຄວາມຜິດພາດ:

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

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

ຖ້າແອັບພລິເຄຊັນໃຊ້ npgsql ແລະສະຫຼັບລະຫວ່າງ nodes ຄິດວ່າພວກມັນຄືກັນທັງຫມົດ, ທ່ານອາດຈະໄດ້ຮັບຂໍ້ຜິດພາດ:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

ຄວາມຜິດພາດນີ້ຈະເກີດຂຶ້ນເນື່ອງຈາກການຜູກມັດກໍາລັງດໍາເນີນຢູ່

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)

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

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

ຕົວຢ່າງ:

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

ແຕ່ເປັນຫຍັງພາກສະຫນາມ LiveNodes ປະກອບມີຕົວເລກ 2 ຢູ່ທົ່ວທຸກແຫ່ງ, ເຖິງແມ່ນວ່າອີງຕາມຄໍາອະທິບາຍຂອງການດໍາເນີນງານຂອງ multimaster ມັນຄວນຈະກົງກັບຈໍານວນ AllNodes=3? ຄໍາຕອບ: ທ່ານຈໍາເປັນຕ້ອງໄດ້ປັບປຸງສະບັບ DBMS.

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

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

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

ແຕ່ນີ້ຈະບໍ່ຮ້າຍແຮງຫຼາຍຖ້າມັນຖືກປະຕິບັດຢ່າງທັນເວລາແລະລົບລ້າງບັນຫາທີ່ເກີດຂື້ນໂດຍທັນທີ.

ແຕ່ນີ້ແມ່ນແນ່ນອນສິ່ງທີ່ບໍ່ເກີດຂຶ້ນ. ປາກົດຂື້ນວ່າຜູ້ຜະລິດບໍ່ມີຊັບພະຍາກອນພຽງພໍທີ່ຈະກໍາຈັດແມງໄມ້ທີ່ກໍານົດໄດ້ທັນທີ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າສູ່ລະບົບກະລຸນາ.