(ج) ياندكس. الصور
جميع الشخصيات وهمية ، والعلامات التجارية مملوكة لأصحابها ، وأي مصادفات عشوائية وبشكل عام ، هذا هو "حكم القيمة الذاتية ، يرجى عدم كسر الباب ...".
لدينا خبرة كبيرة في ترجمة أنظمة المعلومات مع المنطق في قاعدة البيانات من قاعدة بيانات إلى أخرى. في سياق المرسوم الحكومي رقم 1236 بتاريخ 11/16/2016 ، غالبًا ما يكون هذا الانتقال من Oracle إلى Postgresql. كيفية تنظيم العملية بأكبر قدر ممكن من الكفاءة والألم - يمكننا أن نخبرك بشكل منفصل ، اليوم سنتحدث عن ميزات استخدام الكتلة وما هي المشاكل التي قد تواجهها عند إنشاء أنظمة موزعة محملة بدرجة عالية مع منطق معقد في الإجراءات والوظائف.
المفسد - نعم كاب ، RAC و pg multimaster هي حلول مختلفة جدا.
افترض أنك قمت بالفعل بنقل كل المنطق من pl \ sql إلى pg \ sql. واختبارات الانحدار لديك على ما يرام ، والآن أنت بالطبع تفكر في التوسع ، لأنه لا تعتبر اختبارات الحمل مرضية للغاية لك ، خاصة على الأجهزة التي وضعت أصلاً في المشروع ، ضمن نظام إدارة قواعد البيانات المختلف جدًا. افترض أنك وجدت حلاً من البائع المحلي "Postgres Professional" مع خيار يسمى "multimaster" ، والذي يتوفر فقط في الإصدار "الأقصى" من "Postgres Pro Enterprise" والوصف مشابه جدًا لما تحتاجه ، وعند فحصه لأول مرة في رأسي الفكر: "أوه! بدلاً من RAC ، إذن! نعم ، ومع خط الأنابيب الفني في الوطن! "
لكن لا تتسرع في الابتهاج ، وسنصف كذلك لماذا تحتاج إلى معرفة هذه الفروق الدقيقة ، لأن من الصعب تصورها حتى بعد قراءة وثائق المنتج جيدًا. قم بتقييم ما إذا كنت على استعداد لتحديث إصدار DBMS بشكل متكرر مباشرةً على الموقع الصناعي ، مثل بعض العيوب غير متوافقة مع العملية الصناعية ومن الصعب اكتشافها في الاختبار.
ابدأ بقراءة "multimaster" - قسم "التقييد" بعناية على موقع الشركة المصنعة.
أول شيء يمكنك مواجهته هو ميزات تشغيل المعاملات ، ما يسمى وضع "على مرحلتين" ، وأحيانًا ، باستثناء إعادة كتابة منطق الإجراء بالكامل ، لا يمكن إصلاح ذلك. هنا مثال بسيط:
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 أو أعلى ، أو قد لا يساعدك ذلك.
قد تؤدي بعض العمليات التي تحتوي على فهارس إلى حدوث أخطاء حيث يُشار بوضوح إلى أن المشكلة تكمن في "النسخ المتماثل ثنائي الاتجاه" ، في سجلات MTM سترى BDR مباشرة. حقا 2ndQuadrant؟ أوه لا ... لقد اشترينا جهازًا متعدد الوسائط ، إنه مجرد صدفة ، إنه اسم التكنولوجيا.
[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 ، التي ستجعل الزيادات اللازمة لكل عملية sequnce على جميع العقد ، لكن كن مستعدًا لأن هذه الوظيفة لن تعمل في جميع الإصدارات. بالطبع ، يمكنك كتابتها بنفسك ، أو أخذ الكود من github كأساس أو تصحيح نفسك مباشرة في DBMS. في الوقت نفسه ، ستعمل الحقول ذات النوع serial \ bigserial بشكل صحيح ، ولكن لاستخدامها ، على الأرجح ، ستحتاج إلى إعادة كتابة التعليمات البرمجية الخاصة بالإجراءات والوظائف. ربما سيجد شخص ما وظيفة 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.
ما الذي يمكن عمله؟ فقط لا تستخدم بعض الإصدارات. تحتاج إلى معرفتهم ، لأنه لا يظهر الخطأ في إصدار واحد ، وحتى بعد تصحيحه الأول ، قد تواجهه لاحقًا. يجب أيضًا أن تكون مستعدًا لهذا ومن الأفضل تحديد جميع عيوب قواعد البيانات التي يتم إصلاحها من قبل الشركة المصنعة وتغطيتها باختبارات انحدار منفصلة. ثق ، إذا جاز التعبير ، ولكن تحقق.
إذا كان التطبيق يستخدم 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")
لكن لماذا الرقم 2 في كل مكان في حقل LiveNodes ، على الرغم من أنه وفقًا لوصف عمل multimaster ، يجب أن يتوافق مع الرقم AllNodes = 3؟ الإجابة: تحتاج إلى تحديث إصدار DBMS.
وتكون على استعداد لجمع سجلات على جميع العقد ، كما عادة سترى "الخطأ في سجل عقدة أخرى." سيقبل TechSupport جميع العيوب التي تم تحديدها ويبلغك أن الإصدار التالي جاهز ، والذي سيتعين تثبيته في بعض الأحيان مع إيقاف الخدمة ، وأحيانًا لفترة طويلة (اعتمادًا على حجم نظام إدارة قواعد البيانات لديك). لا يجدر بنا أن نأمل في أن تؤدي مشكلات التشغيل إلى إزعاج البائع إلى حد كبير ، وسيتم تنفيذ التحديث بسبب العيوب المحددة بمشاركة ممثلي البائع ، أو بالأحرى ، ليس من الضروري إشراك ممثلي البائع ، حيث يمكنك في النهاية الحصول على مجموعة مفككة بدون نسخ احتياطي للمنتج.
في الواقع ، في ترخيص أي منتج تجاري ، تحذر الشركة المصنعة بأمانة: "يتم توفير هذا البرنامج على أساس" كما هي "وليست شركة Postgres Professional محدودة المسؤولية لتقديم الدعم أو الدعم أو التحديثات أو الإضافات أو التغييرات."
إذا لم تخمن أي نوع من المنتجات الذي نتحدث عنه ، فقد تم اكتساب كل هذه التجربة كنتيجة للتشغيل السنوي لقاعدة Postgres Pro Enterprise. يمكنك الاستنتاج بنفسك ، مثل الرطوبة التي تنمو الفطر.
ولكن سيكون نصف المشكلة ، إذا تم تنفيذها في الوقت المناسب والقضاء على المشاكل التي تنشأ على الفور.
لكن هذا لا يحدث. من الواضح أن موارد الشركة المصنعة لا تكفي لإصلاح الأخطاء التي تم تحديدها بسرعة.