چرا ثبت همگام SQL شما منتظر رفت‌وبرگشت VPN است

تأخیر نوشتن پس از انتقال یک رپلیکا به سایت دوم جهش کرد، و تونل جدیدترین مؤلفه است، پس تقصیر به گردن آن می‌افتد. تونل می‌تواند بی‌گناه باشد: درون یک گروه دسترس‌پذیری با ثبت همگام، نسخه اصلی نمی‌تواند ثبتی را تأیید کند تا وقتی نوشتن گزارش از راه دور کامل شود، بنابراین هر تراکنش هزینه یک رفت‌وبرگشت را می‌پردازد، هر چند مگابیت که پیوند بتواند حمل کند. توان عملیاتی بایت در ثانیه را می‌سنجد، تأخیر می‌سنجد که یک تبادل چقدر طول می‌کشد، و ثبت تنها به یک تبادل کوچک نیاز دارد تا تمام شود. یک عدد بحث را فیصله می‌دهد: مدت ثبت یک تراکنش کوچک، که درون پایگاه داده دسترس‌پذیری و سپس در برابر یک جدول محلی روی همان نمونه سنجیده می‌شود.

نسخه اصلی واقعاً منتظر چه چیزی است

در ثبت همگام، نسخه اصلی تأیید ثبت را نگه می‌دارد تا شریک تأیید کند که رکوردهای گزارشش به‌طور پایدار نوشته شده‌اند. پایدار یعنی در گزارش تراکنش نسخه ثانویه به‌طور ماندگار نوشته شده، نه اینکه در صفحات داده آن بازپخش شده باشد. redo می‌تواند دقایقی عقب بماند بدون آنکه یک میلی‌ثانیه به ثبت نسخه اصلی بیفزاید.

مستندات 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;

نتیجه نخست انتقال گزارش را از redo جدا می‌کند. بالا رفتن log_send_queue_size در حالی که redo_queue_size ثابت می‌ماند یعنی گزارش نرسیده است؛ عکس آن یعنی رسیده و بازپخش عقب است. فقط حالت نخست روی مسیر ثبت قرار دارد.

نتیجه دوم تأیید می‌کند کدام رپلیکاها واقعاً همان‌گونه که فرض می‌کنید پیکربندی شده‌اند، چون حالتی که در یک رخداد پیشین تغییر کرده معمولاً تغییرکرده و مستندنشده می‌ماند. سطری را که به آن اهمیت می‌دهید بخوانید، نه پیش‌فرض گروه: availability_mode_desc و failover_mode_desc برای هر رپلیکا هستند. secondary_lag_seconds فقط در SQL Server 2016 و جدیدتر وجود دارد، پس یک ساخت قدیمی‌تر تنها ستون‌های صف ارسال و redo را برایتان می‌گذارد.

سپس به جای اعتماد به میانگین داشبورد، یک نوشتن نماینده را زمان بگیرید. بلوک زیر را در پایگاه داده دسترس‌پذیری اجرا کنید، سپس آن را دوباره در برابر همان شکل جدول در پایگاهی بیرون از گروه روی همان نمونه اجرا کنید. فاصله میان دو مدت، قیمت تقریبی گزارش دور است و در بحث با تیم شبکه بسیار بهتر از یک نمودار دوام می‌آورد. پس از آن هر بار یک متغیر را تغییر دهید، وگرنه فاصله دیگر معنایی ندارد.

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;

ثبت ناهمگام چه می‌خرد و چه هزینه دارد

با ثبت ناهمگام، نسخه اصلی انتظار تأیید سخت‌سازی دور را متوقف می‌کند، بنابراین رفت‌وبرگشت از مسیر ثبت خارج می‌شود. تأخیر ثبت پایین می‌آید و نسخه ثانویه آزاد است به اندازه‌ای که هیچ‌کس کنترل نمی‌کند عقب بماند. این اصلاحی واقعی برای انتظار و تغییری واقعی در وعده است.

هزینه یک تصمیم درباره نقطه بازیابی است. اگر نسخه اصلی پیش از رسیدن گزارشش به هدف جابه‌جایی در صورت خرابی که واقعاً می‌توانید استفاده کنید بمیرد، بردن سرویس به نسخه ناهمگام تراکنش‌هایی را دور می‌ریزد که برنامه از پیش آن‌ها را ثبت‌شده گزارش کرده بود. هیچ پنجره پیکربندی این را این‌گونه نشان نمی‌دهد، چون پرسشی تجاری درباره زیان قابل‌قبول است نه تنظیم کارایی. پنجره زیان تحمل‌شده را پیش از رخداد بنویسید، نه در میانه آن.

حالت را با صاحب داده، به‌صورت مکتوب، همراه با رویه جابه‌جایی در صورت خرابی برای حالتی که هدف ترجیحی در دسترس نیست توافق کنید. همگام بودن در یک سند طراحی دستورالعمل عملیاتی نیست، و ناهمگام بودن مجوزی برای توقف پایش صف‌ها نیست.

اصلاحی را انتخاب کنید که بعداً بتوانید از آن دفاع کنید

چهار گزینه صادقانه وجود دارد. رفت‌وبرگشت‌های قابل‌اجتناب ثبت را در جایی که معناشناسی برنامه دسته‌بندی را اجازه می‌دهد قطع کنید؛ گلوگاه انتقال یا ذخیره‌سازی سنجیده‌شده را برطرف کنید، که ممکن است به‌جای لوله بزرگ‌تر، حجم گزارش سریع‌تر روی نسخه ثانویه باشد؛ رپلیکا را نزدیک‌تر کنید تا رفت‌وبرگشت کوچک شود؛ یا سیاست حفاظت را شل کنید و پنجره زیان گسترده‌تری را بپذیرید. هر یک تأخیر را با خرج کردن چیز دیگری می‌خرد، و چهارمی دوام را خرج می‌کند. پیش از انتخاب، هزینه را نام ببرید.

با هدف تأخیر بار کاری و نیاز دوام آن که هم‌زمان پیش رویتان است تصمیم بگیرید، چون بهینه‌سازی یکی، دیگری را بی‌صدا خرج می‌کند. سپس همان تراکنشی را که پیش از تغییر سنجیده بودید دوباره اجرا کنید. اصلاحی که نمی‌تواند آن عدد را تکان دهد، حدسی است با بلیت تغییر.

خوانش‌های پیش و پس را در سابقه تغییر نگه دارید. وگرنه نفر بعدی که نوشتن کند را می‌بیند، بررسی را از ابتدا تکرار می‌کند و دوباره با متهم کردن تونل شروع می‌کند.