رپلیکیشن MySQL پس از قطع VPN: نخست هر دو مرحله را بخوانید
مسیر قطع شده به معنای تراکنش های ازدست رفته نیست. گیرنده و اعمال کننده را جداگانه بخوانید، سپس بررسی کنید که منبع هنوز چه چیزی را نگه می دارد.
پایش رپلیکیشن وقتی VPN قطع می شود قرمز می شود و غریزه آن است که یک موقعیت را بازنشانی کنیم. همین غریزه است که یک قطعی شبکه را به مشکل داده تبدیل می کند. مسیر قطع شده هیچ چیزی درباره آنچه رپلیکا دریافت یا اعمال کرده نمی گوید، و این ها دو مرحله با دو وضعیت اند. پیش از تغییر هر چیزی آن ها را جداگانه بخوانید.
دو مرحله، دو پاسخ جداگانه
یک رپلیکای ناهمگام متعارف دو کار انجام می دهد. گیرنده به منبع متصل می شود، رویدادها را می کشد و آن ها را به صورت محلی در گزارش رله می نویسد. اعمال کننده آن گزارش رله را می خواند و رویدادها را روی رپلیکا اجرا می کند. وقتی مسیر می شکند، گیرنده بی درنگ متوقف می شود در حالی که اعمال کننده به پردازش انباشتگی که از پیش روی دیسک است ادامه می دهد. بنابراین یک قطعی دو پرسش متفاوت می سازد: آیا اتصال بازگشته است و آیا کار انباشته اعمال شده است؟ برخورد با آن ها به عنوان یک پرسش، دو وضعیت را در پاسخی گمراه کننده میانگین می گیرد.
بازیابی گیرنده به شما می گوید مسیر برپاست. هیچ چیزی درباره این که اعمال کننده چقدر عقب است یا این که در زمان قطع بودن به خطایی برخورده یا نه نمی گوید.
کانال را با دستور درست بخوانید
در MySQL 8.4، SHOW REPLICA STATUS برای هر کانال پیکربندی شده یک ردیف برمی گرداند، پس ردیف کانالی را که منظورتان است بخوانید نه نخستین ردیف فهرست. Replica_IO_Running گیرنده متصل را از گیرنده ای که در حال اتصال یا متوقف است جدا می کند و Replica_SQL_Running اعمال کننده را توصیف می کند. ستون های خطا را در کنارشان بخوانید، زیرا گیرنده ای که دوباره متصل می شود و بی درنگ شکست می خورد پیامی بر جای می گذارد که هیچ پرچم وضعیتی آن را نشان نخواهد داد. نسخه های قدیمی تر از نام ستون های دیگری استفاده می کنند، پس یک دستور قدیمی را تنها با تغییر نام فرمان ها ترجمه نکنید.
هویت منبع و هر فیلتر پیکربندی شده را هم بررسی کنید. رپلیکایی که به منبع اشتباه اشاره می کند، یا تنگ تر از آنچه فکر می کنید فیلتر شده است، سلامتی گزارش می کند در حالی که چیزی جز آنچه انتظار دارید را رپلیکیت می کند.
چرا یک عدد تأخیر صفر می تواند دروغ بگوید
مقدار تأخیر زمان مهر آخرین رویداد اعمال شده را با زمان کنونی مقایسه می کند. وقتی گیرنده یک ساعت متوقف بوده است، اعمال کننده می تواند انباشتگی را پردازش کند و به پایان آنچه دریافت کرده برسد، و آن گاه عدد به صفر می افتد هرچند رپلیکا یک ساعت از منبع عقب است. این سنجه صف اعمال کننده را می سنجد، نه به روز بودن رپلیکا را.
در عوض تراکنش های اجرا شده را با آنچه منبع در دسترس دارد مقایسه کنید. این مقایسه در برابر گیرنده متوقف شده دوام می آورد.
نگهداری، پنجره واقعی بازیابی را تعیین می کند
رسیدن به منبع مستلزم آن است که منبع هنوز تراکنش هایی را که رپلیکا نیاز دارد نگه دارد. وقتی آن ها پاک شدند، رپلیکا نمی تواند آن ها را بگیرد و هیچ مقدار اتصال دوباره این را تغییر نمی دهد.
با جایگاه یابی خودکار GTID شکست صریح است: رپلیکا تاریخی را می خواهد که منبع دیگر نگه نمی دارد و از ادامه امتناع می کند. آن گاه گزینه ها گرفتن رویدادهای گم شده از منبعی است که هنوز آن ها را دارد، یا بازسازی از یک پشتیبان و رها کردنش تا برسد. پریدن از شکاف رسیدن نیست و رپلیکایی بر جای می گذارد که داده هایش بی صدا ناقص است. پنجره را با مقایسه مدت قطعی مورد انتظار با نگهداری گزارش دودویی روی منبع و نرخ تغییر برنامه ریزی کنید، زیرا آن سه عدد تعیین می کنند که آیا قطعی اصلا قابل بازیابی است.
رسیدن را بررسی کنید، نه رنگ یک نشانگر
مسیر را بازگردانید، شامل تفکیک نام و امنیت انتقال، سپس ببینید آیا کانال موجود بر اساس سیاست خودش دوباره متصل می شود. پیش از مداخله بازه ای مشخص به آن بدهید و پیشرفت دریافت و اعمال را در دو سر آن بازه ثبت کنید. کانالی که دوباره راه اندازی می شود و کانالی که به روز است یافته های متفاوتی هستند.
تأیید کنید که اعمال کننده به موقعیت کنونی منبع رسیده است، نه فقط به پایان انباشتگی قدیمی. بررسی کنید که خطایی در اعمال کننده در انتظار نیست، زیرا یک رویداد شکست خورده پیشرفت را متوقف می کند در حالی که گیرنده همچنان اتصال را گزارش می دهد. سپس شواهد را ثبت کنید: نام کانال، وضعیت هر دو مرحله، موقعیت اجرا شده و زمان. نشانگر سبز یک ادعاست؛ موقعیت یک واقعیت است.