🥇“เกี่ยวกับ แต่ไม่ใช่คลัสเตอร์” หรือวิธีที่เราแทนที่ DBMS ที่นำเข้า

(ts) Yandex.Images

ตัวละครทั้งหมดเป็นเรื่องสมมติ เครื่องหมายการค้าเป็นของเจ้าของ สิ่งที่คล้ายกันใดๆ เกิดขึ้นแบบสุ่ม และโดยทั่วไป นี่คือ "การตัดสินคุณค่าเชิงอัตนัยของฉัน โปรดอย่าทำลายประตู..."

เรามีประสบการณ์มากมายในการถ่ายโอนระบบข้อมูลด้วยตรรกะไปยังฐานข้อมูลจาก DBMS หนึ่งไปยังอีกฐานข้อมูลหนึ่ง ในบริบทของคำสั่งของรัฐบาลหมายเลข 1236 เมื่อวันที่ 16.11.2016 พฤศจิกายน XNUMX นี่มักจะเป็นการโอนจาก Oracle ไปยัง Postgresql เราสามารถบอกคุณแยกกันถึงวิธีจัดระเบียบกระบวนการอย่างมีประสิทธิภาพและไม่ยุ่งยากเท่าที่เป็นไปได้ วันนี้เราจะพูดถึงคุณสมบัติของการใช้คลัสเตอร์และปัญหาใดบ้างที่สามารถพบได้เมื่อสร้างระบบแบบกระจายที่มีโหลดสูงด้วยตรรกะที่ซับซ้อนในขั้นตอนและฟังก์ชัน

สปอยเลอร์ – ใช่ cap, RAC และ pg multimaster เป็นโซลูชันที่แตกต่างกันมาก

สมมติว่าคุณได้ถ่ายโอนตรรกะทั้งหมดจาก plsql ไปยัง pgsql แล้ว และการทดสอบการถดถอยของคุณค่อนข้างโอเค แน่นอนว่าตอนนี้คุณกำลังคิดที่จะปรับขนาด เพราะ... การทดสอบโหลดไม่ได้ทำให้คุณมีความสุขมากนัก โดยเฉพาะกับฮาร์ดแวร์ที่เดิมรวมอยู่ในโปรเจ็กต์ สำหรับ DBMS ที่แตกต่างกันมากนั้น สมมติว่าคุณพบวิธีแก้ปัญหาจากผู้ขายในประเทศ "Postgres Professional" พร้อมตัวเลือกที่เรียกว่า "multimaster" ซึ่งมีเฉพาะใน "Postgres Pro Enterprise" เวอร์ชัน "สูงสุด" เท่านั้นและตามคำอธิบาย - มันคล้ายกับอะไรมาก คุณต้องการ และด้วยการศึกษาอย่างผิวเผินครั้งแรก ความคิดนี้ก็เข้ามาในหัวของฉัน: "โอ้! แค่นั้นแหละแทนที่จะเป็น RAC! และถึงแม้จะมีท่อทางเทคนิคในบ้านเกิดของเรา!”

แต่อย่ารีบเร่งที่จะชื่นชมยินดี แล้วเราจะอธิบายเพิ่มเติมว่าทำไมคุณต้องรู้ความแตกต่างเหล่านี้ เพราะ... สิ่งเหล่านี้คาดเดาได้ยาก แม้ว่าจะอ่านเอกสารประกอบผลิตภัณฑ์อย่างละเอียดแล้วก็ตาม ประเมินว่าคุณพร้อมที่จะอัปเดตเวอร์ชัน DBMS โดยตรงบนไซต์ที่ใช้งานจริงบ่อยครั้งหรือไม่ เนื่องจาก ข้อบกพร่องบางอย่างเข้ากันไม่ได้กับการใช้งานในอุตสาหกรรมและตรวจพบได้ยากในระหว่างการทดสอบ
เริ่มต้นด้วยการอ่านส่วน "มัลติมาสเตอร์" - "ข้อจำกัด" บนเว็บไซต์ของผู้ผลิตอย่างละเอียด

สิ่งแรกที่คุณอาจพบคือลักษณะเฉพาะของวิธีการทำงานของธุรกรรมที่เรียกว่า โหมด "สองเฟส" และบางครั้งก็ไม่มีวิธีแก้ไขปัญหานี้ยกเว้นโดยการเขียนตรรกะทั้งหมดของขั้นตอนของคุณใหม่ นี่เป็นตัวอย่างง่ายๆ:

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.

จากนั้นคุณสามารถต่อสู้เป็นเวลานานด้วยการล็อคตายในเวอร์ชัน 10.5, 10.6 และวิธีแก้ปัญหาเดียวที่ทราบซึ่งทำลายสาระสำคัญทั้งหมดของคลัสเตอร์คือการลบตาราง "ปัญหา" ออกจากคลัสเตอร์เช่น ทำ make_table_local แต่อย่างน้อยก็จะทำให้มันทำงานได้ และจะไม่ทำให้ทุกอย่างถูกระงับเนื่องจากการรอธุรกรรมที่ค้างอยู่ หรือติดตั้งอัปเดตเป็นเวอร์ชัน 11.2 ซึ่งน่าจะช่วยได้ แต่อาจจะไม่ลืมที่จะตรวจสอบ

ในบางเวอร์ชัน คุณจะได้รับล็อคที่ลึกลับยิ่งกว่านี้:

username= mtm и backend_type = background worker

และในสถานการณ์เช่นนี้ การอัปเดต DBMS เวอร์ชันเป็น 11.2 ขึ้นไปเท่านั้นที่จะช่วยคุณได้ หรืออาจจะไม่ช่วยก็ได้

การดำเนินการบางอย่างกับดัชนีอาจทำให้เกิดข้อผิดพลาด ซึ่งระบุอย่างชัดเจนว่าปัญหาอยู่ในการจำลองแบบสองทิศทาง คุณจะเห็น BDR โดยตรงในบันทึก MTM มันเป็นควอแดรนท์ที่ 2 จริงเหรอ? ไม่... เราซื้อมัลติมาสเตอร์มา มันเป็นแค่เรื่องบังเอิญ มันเป็นชื่อของเทคโนโลยี

[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.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:

…
 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" เวอร์ชัน 11.2

คุณจำเป็นต้องรู้แยกกันว่าลำดับซึ่งเป็นอ็อบเจ็กต์ของฐานข้อมูลที่ถูกจำลองแบบ ไม่มีค่าจากต้นทางถึงปลายทางทั่วทั้งคลัสเตอร์ แต่ละลำดับจะอยู่ภายในเครื่องสำหรับแต่ละโหนด และหากคุณมีฟิลด์ที่มีข้อจำกัดเฉพาะและลำดับการใช้งาน จากนั้นคุณสามารถเพิ่มได้เท่ากับหมายเลขโหนดในคลัสเตอร์เท่านั้นเนื่องจาก โหนดในคลัสเตอร์มากที่สุดเท่าที่จะเป็นไปได้ ลำดับและ int จะเติบโตเร็วกว่าที่คุณคาดไว้ เพื่อให้การทำงานกับลำดับในผลิตภัณฑ์ง่ายขึ้น คุณจะพบฟังก์ชัน alter_sequences ซึ่งจะเพิ่มขั้นตอนที่จำเป็นสำหรับแต่ละลำดับบนโหนดทั้งหมด แต่ต้องเตรียมพร้อมว่าฟังก์ชันนี้จะไม่ทำงานในทุกเวอร์ชัน แน่นอนคุณสามารถเขียนเองได้โดยใช้โค้ดจาก github เป็นพื้นฐานหรือแก้ไขด้วยตนเองโดยตรงใน DBMS ในกรณีนี้ ช่องที่มีประเภท serialbigserial จะทำงานได้อย่างถูกต้องมากขึ้น แต่หากต้องการใช้งาน เป็นไปได้มากว่าคุณจะต้องเขียนโค้ดของขั้นตอนและฟังก์ชันของคุณใหม่ บางทีบางคนอาจพบว่าฟังก์ชัน monotonic_sequences มีประโยชน์

ก่อน Postgres Pro Enterprise เวอร์ชัน 11.2 การจำลองแบบจะทำงานได้ก็ต่อเมื่อมีคีย์หลักที่ไม่ซ้ำกัน โปรดคำนึงถึงสิ่งนี้ด้วยเมื่อพัฒนา

ฉันอยากจะพูดถึงลักษณะเฉพาะของวิธีการทำงานของ 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 และสลับระหว่างโหนดโดยคิดว่าเหมือนกันทั้งหมด คุณอาจได้รับข้อผิดพลาด:

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

ข้อผิดพลาดนี้จะเกิดขึ้นเนื่องจากการผูกข้อมูลอยู่ระหว่างดำเนินการ

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

ประเภทคอมโพสิตเมื่อเริ่มต้นแอปพลิเคชันสำหรับการเชื่อมต่อทั้งหมด เป็นผลให้เราได้รับตัวระบุจากโหนดหนึ่งและเมื่อร้องขอบนโหนดอื่นจะไม่ตรงกันซึ่งเป็นผลมาจากการส่งคืนข้อผิดพลาดเช่น การทำงานอย่างโปร่งใสกับประเภทคอมโพสิตในคลัสเตอร์จะไม่สามารถทำได้สำหรับบางแอปพลิเคชันหากไม่มีการเขียนซ้ำฝั่งแอปพลิเคชันเพิ่มเติม (หากคุณจัดการได้)

ดังที่เราทุกคนทราบกันดีว่าการประเมินสถานะโดยรวมของคลัสเตอร์มีความสำคัญมากสำหรับการวินิจฉัยและมาตรการการปฏิบัติงานระหว่างการดำเนินการ ในผลิตภัณฑ์คุณจะพบฟังก์ชันบางอย่างที่จะทำให้ชีวิตของคุณง่ายขึ้น แต่บางครั้งอาจให้สิ่งที่แตกต่างไปจากเดิมอย่างสิ้นเชิง คุณและแม้แต่ผู้ผลิตเองก็คาดหวังจากสิ่งเหล่านั้นอย่างที่คุณคาดหวัง

ตัวอย่างเช่น:

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 ทุกที่ แม้ว่าตามคำอธิบายของการทำงานของมัลติมาสเตอร์แล้ว ควรสอดคล้องกับหมายเลข AllNodes=3 คำตอบ: คุณต้องอัปเดตเวอร์ชัน DBMS

และเตรียมรวบรวม Log ของทุก Node เพราะ... โดยปกติคุณจะเห็น "ข้อผิดพลาดอยู่ในบันทึกของโหนดอื่น" ฝ่ายสนับสนุนด้านเทคนิคจะยอมรับข้อบกพร่องทั้งหมดที่คุณระบุและแจ้งให้คุณทราบว่าเวอร์ชันถัดไปพร้อมใช้งานแล้ว ซึ่งบางครั้งจำเป็นต้องติดตั้งโดยที่บริการหยุดทำงาน บางครั้งเป็นเวลานาน (ขึ้นอยู่กับขนาดของ DBMS ของคุณ) คุณไม่ควรหวังว่าปัญหาการปฏิบัติงานจะรบกวนผู้ขายอย่างมาก และการอัปเดตเนื่องจากข้อบกพร่องที่ระบุจะดำเนินการโดยมีส่วนร่วมของตัวแทนของผู้ขาย หรือคุณไม่จำเป็นต้องเกี่ยวข้องกับตัวแทนของผู้ขายด้วยซ้ำ เนื่องจากใน ท้ายที่สุดคุณสามารถจบลงด้วยคลัสเตอร์ที่ถูกแยกส่วนในการผลิตโดยไม่ต้องสำรองข้อมูล

จริงๆ แล้ว ในใบอนุญาตสำหรับผลิตภัณฑ์เชิงพาณิชย์ ผู้ผลิตเตือนอย่างจริงใจว่า "ซอฟต์แวร์นี้จัดทำขึ้น "ตามสภาพ" และบริษัท Postgres Professional Limited Liability Company ไม่มีภาระผูกพันในการให้การบำรุงรักษา การสนับสนุน การอัปเดต การขยายเวลา หรือการเปลี่ยนแปลง"

หากคุณยังไม่สามารถเดาได้ว่าเรากำลังพูดถึงผลิตภัณฑ์ใด ประสบการณ์ทั้งหมดนี้ได้รับมาจากการดำเนินงานฐานข้อมูล Postgres Pro Enterprise ที่ยาวนานหนึ่งปี คุณสามารถสรุปได้เองว่ามันชื้นมากจนเห็ดโต

แต่สิ่งนี้คงไม่เลวร้ายนักหากทำได้ทันเวลาและขจัดปัญหาที่เกิดขึ้นโดยทันที

แต่นี่คือสิ่งที่ไม่เกิดขึ้นอย่างแน่นอน เห็นได้ชัดว่าผู้ผลิตไม่มีทรัพยากรเพียงพอที่จะกำจัดจุดบกพร่องที่ระบุได้ทันที

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

คุณมีประสบการณ์ในการเปลี่ยนจาก DBMS ต่างประเทศ/กรรมสิทธิ์ไปเป็น DBMS ฟรี/ในประเทศหรือไม่?

21,3% ใช่บวก 10
10,6% ใช่ลบ5
21,3% ไม่ DBMS ไม่ได้เปลี่ยนแปลง10
4,3% DBMS มีการเปลี่ยนแปลง แต่ไม่มีอะไรเปลี่ยนแปลง2
42,6% ดูผลลัพธ์20

ผู้ใช้ 47 คนโหวต ผู้ใช้ 12 รายงดออกเสียง

ที่มา: will.com

“Pro แต่ไม่ใช่คลัสเตอร์” หรือวิธีที่เราแทนที่ DBMS ที่นำเข้า

คุณมีประสบการณ์ในการเปลี่ยนจาก DBMS ต่างประเทศ/กรรมสิทธิ์ไปเป็น DBMS ฟรี/ในประเทศหรือไม่?

เพิ่มความคิดเห็น ยกเลิกการตอบ