آپ کا ہم وقت SQL کمٹ VPN کے آنے جانے کا انتظار کیوں کرتا ہے

دوسری سائٹ پر نقل منتقل ہونے کے بعد لکھنے کی تاخیر اچھل گئی، اور ٹنل سب سے نیا جزو ہے، اس لیے الزام اسی پر جاتا ہے۔ ٹنل بے قصور ہو سکتی ہے: ہم وقت کمٹ والے دستیابی گروپ کے اندر بنیادی نقل دور دراز لاگ کی تحریر مکمل ہونے سے پہلے کمٹ تسلیم نہیں کر سکتی، اس لیے ہر ٹرانزیکشن آنے جانے کے سفر کی قیمت ادا کرتی ہے، لنک کتنے ہی میگا بٹ لے جا سکے۔ تھرو پٹ فی سیکنڈ بائٹس ناپتا ہے، تاخیر ناپتی ہے کہ ایک تبادلے میں کتنا وقت لگتا ہے، اور کمٹ کو مکمل ہونے کے لیے صرف ایک چھوٹا تبادلہ درکار ہوتا ہے۔ ایک عدد ہی بحث طے کرتا ہے: چھوٹی ٹرانزیکشن کے کمٹ کی مدت، جو دستیابی ڈیٹا بیس کے اندر اور پھر اسی انسٹینس پر مقامی جدول کے سامنے دوبارہ ناپی جاتی ہے۔

بنیادی نقل دراصل کس چیز کا انتظار کرتی ہے

ہم وقت کمٹ کے تحت بنیادی نقل کمٹ کی منظوری روکے رکھتی ہے جب تک ساتھی یہ تصدیق نہ کرے کہ اس کے لاگ ریکارڈ مستحکم ہو گئے ہیں۔ مستحکم کا مطلب ہے ثانوی کے ٹرانزیکشن لاگ میں پائیدار طور پر لکھا گیا، اس کے ڈیٹا صفحات میں دوبارہ نہیں چلایا گیا۔ redo بنیادی نقل کے کمٹ میں ایک ملی سیکنڈ بھی شامل کیے بغیر منٹوں پیچھے رہ سکتا ہے۔

دستیابی کے طریقوں کے بارے میں Microsoft کی دستاویز اس مصافحے کی وضاحت کرتی ہے اور بتاتی ہے کہ ساتھی کے باہر ہونے پر پلیٹ فارم کیا کرتا ہے۔ ہم وقت کے طور پر نشان زد نقل انتظار کا اصول ہے، ہر کمٹ کے لیے صحت مند دور دراز نقل ہونے کا دائمی وعدہ نہیں۔ منقطع راستہ الگ سے متعین ہے، اور یہ صرف یہ نہیں کہ کمٹ ناکام ہو جائے۔

اس لیے جو انتظار آپ دیکھتے ہیں وہ ایک مجموعہ ہے: لاگ کی منتقلی، دونوں میزبانوں پر شیڈولنگ اور دور دراز ذخیرے میں تحریر۔ بھرا ہوا لاگ حجم رکھنے والی ثانوی نقل ایسا وقت جوڑتی ہے جو کوئی رفتار جانچ ظاہر نہیں کرے گی۔ شکایت میں VPN کا نام آنے پر وہ ڈسک شاذ و نادر ہی ناپی جاتی ہے۔

بینڈ وڈتھ آنے جانے کی تاخیر نہیں ہے

رفتار کی جانچ راستے کو مختصر وقت کے لیے بھر دیتی ہے اور شرح بتاتی ہے۔ کمٹ کچھ زیادہ تنگ مانگتا ہے: چھوٹے پیغام کو دوسری طرف پہنچنے، محفوظ ہونے اور واپس آنے میں کتنا وقت لگتا ہے۔ راستے کی لمبائی، قطاریں اور پیکٹ کا ضیاع وہ عدد طے کرتے ہیں، اور فراہم کنندہ حد بڑھانے پر ان میں سے کوئی بہتر نہیں ہوتا۔

اس لیے «تیز» ٹنل بہت سی چھوٹی متواتر ٹرانزیکشنوں سے بنے لکھائی کے بھاری کام پر نظر آنے والا جرمانہ شامل کر سکتی ہے۔ وہی کل بائٹس ہزار کمٹوں میں تقسیم ہوں تو آنے جانے کا سفر ہزار بار ادا کرتی ہیں؛ ایک بڑی منتقلی اسے ایک بار ادا کرتی ہے۔

نیٹ ورک کے مالک سے کہیں کہ نمائندہ بوجھ کے تحت نقل کے راستے ہی پر تاخیر اور ضیاع ناپے۔ دفتر کے لیپ ٹاپ سے 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;

غیر ہم وقت کمٹ کیا خریدتا ہے، اور کیا خرچ کرتا ہے

غیر ہم وقت کمٹ کے ساتھ بنیادی نقل دور دراز مستحکم کرنے کی تصدیق کا انتظار چھوڑ دیتی ہے، اس لیے آنے جانے کا سفر کمٹ کے راستے سے نکل جاتا ہے۔ کمٹ کی تاخیر کم ہوتی ہے اور ثانوی نقل اتنا پیچھے رہنے کو آزاد ہوتی ہے جتنا کوئی کنٹرول نہیں کرتا۔ یہ انتظار کی حقیقی اصلاح اور وعدے کی حقیقی تبدیلی ہے۔

قیمت بازیابی کے مقام کا فیصلہ ہے۔ اگر بنیادی نقل اپنے لاگ کو اس فیل اوور ہدف تک پہنچنے سے پہلے مر جائے جو آپ واقعی استعمال کر سکتے ہیں، تو سروس کو غیر ہم وقت نقل پر منتقل کرنا وہ ٹرانزیکشنز پھینک دیتا ہے جنہیں ایپلیکیشن پہلے ہی کمٹ بتا چکی تھی۔ کوئی تشکیلاتی مکالمہ اسے ایسے پیش نہیں کرتا، کیونکہ یہ قابل قبول نقصان کا کاروباری سوال ہے، کارکردگی کی ترتیب نہیں۔ برداشت شدہ نقصان کی کھڑکی واقعے سے پہلے لکھیں، اس کے دوران نہیں۔

ڈیٹا کے مالک کے ساتھ موڈ پر تحریری طور پر اتفاق کریں، پسندیدہ ہدف کے دستیاب نہ ہونے کی صورت کے لیے فیل اوور طریقہ کار کے ساتھ۔ ڈیزائن دستاویز میں ہم وقت آپریشنل گائیڈ نہیں ہے، اور غیر ہم وقت قطاروں کو دیکھنا بند کرنے کا لائسنس نہیں ہے۔

ایسی اصلاح چنیں جس کا آپ بعد میں دفاع کر سکیں

چار ایماندار اختیارات ہیں۔ جہاں ایپلیکیشن کی معنیات بیچنگ کی اجازت دیں وہاں ناقابلِ اجتناب کمٹ کے آنے جانے کے سفر کاٹیں؛ آپ نے جو نقل و حمل یا ذخیرہ کی رکاوٹ ناپی اسے ٹھیک کریں، جس کا مطلب ثانوی پر بڑے پائپ کی بجائے تیز لاگ حجم ہو سکتا ہے؛ سفر چھوٹا ہونے کے لیے نقل کو قریب لائیں؛ یا حفاظتی پالیسی نرم کریں اور وسیع نقصان کی کھڑکی قبول کریں۔ ہر ایک تاخیر کچھ اور خرچ کر کے خریدتی ہے، اور چوتھی پائیداری خرچ کرتی ہے۔ چننے سے پہلے خرچ کا نام لیں۔

کام کے بوجھ کا تاخیر ہدف اور اس کی پائیداری کی ضرورت ایک ساتھ سامنے رکھ کر فیصلہ کریں، کیونکہ ایک کو بہتر بنانا دوسرے کو خاموشی سے خرچ کرتا ہے۔ پھر تبدیلی سے پہلے ناپی گئی وہی ٹرانزیکشن دوبارہ چلائیں۔ جو اصلاح اس عدد کو ہلا نہیں سکتی وہ تبدیلی ٹکٹ پہنے قیاس ہے۔

تبدیلی کے ریکارڈ میں پہلے اور بعد کے پڑھنے محفوظ رکھیں۔ ورنہ سست لکھائی دیکھنے والا اگلا شخص تحقیق شروع سے دہراتا ہے اور پھر ٹنل کو الزام دینے سے شروع کرتا ہے۔