لماذا ينتظر تثبيت SQL المتزامن رحلة الذهاب والإياب عبر VPN

قفز كمون الكتابة بعد انتقال نسخة متماثلة إلى الموقع الثاني، والنفق هو أحدث مكوّن، لذا يحمل اللوم. قد يكون النفق بريئًا: داخل مجموعة توفر ذات تثبيت متزامن لا يمكن للأساسي أن يقرّ بتثبيت حتى تكتمل كتابة سجل بعيد، لذا تدفع كل معاملة رحلة ذهاب وإياب مهما كان عدد الميغابتات التي يستطيع الرابط حملها. تقيس الإنتاجية البايتات في الثانية، ويقيس الكمون مدة تبادل واحد، ولا يحتاج التثبيت إلا إلى تبادل صغير واحد لينتهي. رقم واحد يحسم الجدل: مدة تثبيت معاملة صغيرة، مقاسة داخل قاعدة بيانات التوفر ثم مقابل جدول محلي على النسخة نفسها.

ما الذي ينتظره الأساسي فعليًا

في ظل التثبيت المتزامن يُبقي الأساسي إقرار التثبيت معلّقًا حتى تؤكد الشريكة أن سجلات سجلها أصبحت مُصلَّبة. التصلّب يعني كتابة دائمة في سجل معاملات الثانوية، لا إعادة تنفيذ في صفحات بياناتها. يمكن أن تتأخر إعادة التنفيذ دقائق من دون أن تضيف ميلي ثانية واحدة إلى تثبيت الأساسي.

توثيق Microsoft لأوضاع التوفر يشرح تلك المصافحة ويصف ما تفعله المنصة عندما تسقط شريكة. النسخة الموسومة كمتزامنة هي قاعدة بشأن الانتظار، وليست وعدًا دائمًا بوجود نسخة بعيدة سليمة لكل تثبيت. يُعرَّف المسار المنفصل على حدة، وليس مجرّد أن التثبيت يفشل.

إذن فما تراه من انتظار هو مجموع: نقل السجل، والجدولة على المضيفين، وكتابة التخزين البعيد. الثانوية ذات حجم السجل المشبع تضيف وقتًا لن يُظهره أي اختبار سرعة. ونادرًا ما يُقاس ذلك القرص عندما يذكر الشكوى اسم VPN.

النطاق الترددي ليس تأخير رحلة الذهاب والإياب

يُغرق اختبار السرعة المسار لفترة وجيزة ويبلّغ عن معدل. أما التثبيت فيطلب شيئًا أضيق: كم تستغرق رسالة صغيرة لتصل إلى الجانب الآخر، ويُخزَّن، ويعود. طول المسار والانتظار في الصفوف وفقدان الحزم تحدد ذلك الرقم، ولا يتحسن أي منها عندما يرفع المزود السقف.

لذا يمكن لنفق «سريع» أن يضيف عبئًا ظاهرًا على حمل عمل كثيف الكتابة مبني على معاملات صغيرة متتابعة كثيرة. المجموع نفسه من البايتات إذا قُسِّم على ألف تثبيت يدفع رحلة الذهاب والإياب ألف مرة؛ أما النقل الدفعي الواحد فيدفعها مرة واحدة.

اطلب من مالك الشبكة قياس التأخير والفقدان على مسار النسخة نفسه تحت حمل تمثيلي. أمر ping من حاسوب محمول في مكتب إلى بوابة VPN، أو اختبار سرعة إلى عقدة قريبة، لا ينسب إلا القليل جدًا إلى المسار الذي يسلكه السجل فعلًا. اجعل نافذة القياس تتداخل مع الساعات التي تكون فيها الكتابة بطيئة.

اقرأ حالة النسخة قبل أن تغيّر أي شيء

ابدأ بما تبلغ به النسخ عن نفسها، لأن الجانبين قد يختلفان حول مدى سلامة الشراكة و متوسط لوحة المعلومات يخفي أي صف يتحرك. تستجيب الاستعلامات أدناه لأسئلة مختلفة: أحدها يقرأ حالة التكرار لكل قاعدة بيانات، والآخر يقرأ كيفية تهيئة كل نسخة. شغّل كليهما قبل لمس أي وضع.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

النتيجة الأولى تفصل نقل السجل عن إعادة التنفيذ. صعود log_send_queue_size بينما يبقى redo_queue_size ثابتًا يعني أن السجل لم يصل؛ والعكس يعني أنه وصل وأن إعادة التشغيل متأخرة. الحالة الأولى وحدها تقع على مسار التثبيت.

النتيجة الثانية تؤكد أي النسخ مهيأة فعلًا كما تفترض، لأن الوضع الذي تغيّر أثناء حادث سابق يبقى غالبًا متغيرًا وغير موثّق. اقرأ الصف الذي يهمك بدلًا من الافتراضي للمجموعة: availability_mode_desc و failover_mode_desc لكل نسخة. secondary_lag_seconds موجود فقط في SQL Server 2016 وما بعده، لذا يتركك إصدار أقدم مع عمودَي قائمة إرسال السجل وإعادة التنفيذ فقط.

ثم قِس كتابة تمثيلية بدلًا من الثقة بمتوسط لوحة المعلومات. شغّل الكتلة أدناه في قاعدة بيانات التوفر، ثم شغّلها مرة أخرى على بنية الجدول نفسها في قاعدة بيانات خارج المجموعة على النسخة نفسها. الفجوة بين المددين ثمن تقريبي للسجل البعيد، وهي تصمد في نقاش مع فريق الشبكة أفضل بكثير من رسم بياني. غيّر متغيرًا واحدًا في كل مرة بعد ذلك، وإلا فقدت الفجوة معناها.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

ماذا يشتري التثبيت غير المتزامن، وماذا يكلّف

مع التثبيت غير المتزامن يتوقف الأساسي عن انتظار تأكيد التصلّب البعيد، فتخرج رحلة الذهاب والإياب من مسار التثبيت. ينخفض كمون التثبيت وتصبح الثانوية حرة في التخلف بمقدار لا يتحكم به أحد. هذا إصلاح حقيقي للانتظار وتغيير حقيقي للوعد.

الثمن قرار بشأن نقطة الاسترداد. إذا مات الأساسي قبل أن يصل سجله إلى هدف تحويل يمكنك استخدامه فعلًا، فإن دفع الخدمة إلى النسخة غير المتزامنة يتجاهل معاملات أبلغ التطبيق عنها كأنها مثبتة. لا يعرض أي مربع حوار إعداد الأمر بهذه الصورة، لأنه سؤال عمل عن الخسارة المقبولة لا إعداد أداء. اكتب نافذة الخسارة المسموح بها قبل الحادث، لا أثناءه.

اتفق على الوضع مع من يملك البيانات، كتابةً، إلى جانب إجراء التحويل عند الفشل في الحالة التي يكون فيها الهدف المفضّل غير متاح. المتزامن في وثيقة تصميم ليس دليل تشغيل، وغير المتزامن ليس رخصة للتوقف عن مراقبة الصفوف.

اختر إصلاحًا يمكنك الدفاع عنه لاحقًا

توجد أربعة خيارات صادقة. اقطع رحلات التثبيت التي يمكن تجنبها حيث تسمح دلالات التطبيق بالتجميع؛ أو أصلح عنق زجاجة في النقل أو التخزين قِسته، وقد يعني ذلك حجم سجل أسرع على الثانوية بدلًا من أنبوب أكبر؛ أو قرّب النسخة حتى تتقلص رحلة الذهاب والإياب؛ أو خفف سياسة الحماية واقبل نافذة خسارة أوسع. كل خيار يشتري الكمون بإنفاق شيء آخر، والرابع ينفق المتانة. سمِّ الإنفاق قبل أن تختار.

قرّر وأمامك هدف كمون حمل العمل ومتطلب المتانة في الوقت نفسه، لأن تحسين أحدهما ينفق الآخر بهدوء. ثم أعد تشغيل المعاملة نفسها التي قِستها قبل التغيير. الإصلاح الذي لا يستطيع تحريك ذلك الرقم تخمين يرتدي بطاقة تغيير.

احتفظ بقراءات قبل وبعد في سجل التغيير. وإلا فإن الشخص التالي الذي يرى كتابة بطيئة يعيد التحقيق من البداية ويبدأ بلوم النفق من جديد.