در این مقاله
انتشار بدون قطعی فقط تعویض آرام کانتینر نیست. اگر نسخه جدید ستون دیتابیس را حذف کند در حالی که نمونه قدیمی هنوز درخواست می‌گیرد، چند Replica هم نمی‌تواند سازگاری را حفظ کند. هدف عملی، انتشار کم‌ریسک با قرارداد داده سازگار، آزمون آمادگی و مسیر بازگشت روشن است؛ «صفر قطعی» بدون اندازه‌گیری و شناخت وابستگی‌ها یک تضمین قابل دفاع نیست.
در این مقاله یک برنامه فرضی سفارش را در نظر می‌گیریم که نام فیلدی را تغییر میدهد. داده ساختگی است و هیچ مهاجرتی روی دیتابیس مشتری اجرا نمی‌شود. الگوی Expand و Contract را قدم‌به‌قدم بررسی می‌کنیم و توضیح می‌دهیم چه چیزی به برنامه، چه چیزی به دیتابیس و چه چیزی به رفتار واقعی پلتفرم مربوط است. وجود قابلیت Blue-green آماده در پاستا از این الگو نتیجه گرفته نمی‌شود.
مرز انتشار برنامه و تغییر داده را جدا کنید
ایمیج برنامه قابل نسخه‌گذاری است، اما داده پس از هر درخواست تغییر میکند. برگشتن به ایمیج قبلی، سفارش جدید یا ستون حذف‌شده را خودکار برنمی‌گرداند. پیش از تغییر، فهرست کنید چه نسخه‌هایی ممکن است هم‌زمان اجرا شوند و هر کدام چه طرح داده‌ای را می‌خوانند. درخواست HTTP، Worker قدیمی و کار زمان‌بندی‌شده همگی مصرف‌کننده قرارداد داده‌اند.
چک‌لیست آمادگی تولید برای ساختن مدارک پایه مفید است. این راهنما یک بخش آن را عمیق‌تر میکند: چگونه تغییر داده را در چند انتشار مستقل پخش کنیم. اگر همه تغییرها را در یک اجرای بزرگ جمع کنید، تشخیص شکست و تصمیم بازگشت دشوارتر میشود و فشار روی زمان انتشار افزایش می‌یابد.
Expand و Contract به زبان ساده
در مرحله Expand، شکل جدید را بدون حذف شکل قدیمی اضافه می‌کنید. در مرحله انتقال، برنامه و داده به‌تدریج با قرارداد جدید سازگار میشوند. در مرحله Contract، بعد از اثبات نبود مصرف‌کننده قدیمی، بخش قدیمی حذف میشود. این ترتیب به معنی بی‌نیازی از قفل، آزمون بار یا بکاپ نیست؛ هر دستور دیتابیس باید جدا از نظر اثر عملی بررسی شود.
مثلاً اگر می‌خواهید full_name را به display_name تبدیل کنید، حذف و تغییر نام یک‌باره ممکن است نسخه قبلی را بشکند. افزودن ستون جدید، انتقال کنترل‌شده داده و انتشار خواننده سازگار مسیر متفاوتی است. اینکه دو ستون را چه مدت و چگونه هماهنگ نگه دارید به قواعد برنامه وابسته است؛ نسخه‌ای که فقط از ستون جدید می‌نویسد ممکن است بازگشت به کد قدیمی را ناممکن کند.
قبل از تغییر، خط مبنا و بکاپ بسازید
تعداد ردیف، اندازه جدول، نرخ نوشتن و کندترین Queryهای مرتبط را ثبت کنید. بازه خلوت را بدون نگاه به کارهای پس‌زمینه انتخاب نکنید؛ ممکن است هم‌زمان گزارش شبانه یا ورود داده اجرا شود. روش بکاپ و بازیابی باید با نسخه دیتابیس و زمان قابل تحمل از دست رفتن داده هماهنگ باشد. فایل موجود در فضای ذخیره به‌تنهایی شاهد بازیابی نیست.
آزمایش بازیابی را روی مقصد جدا انجام دهید. زمان، نتیجه خواندن و امکان اجرای نسخه برنامه را ثبت کنید. اگر دسترسی یا ابزار لازم ندارید، آن را پیش از انتشار حل کنید، نه هنگام شکست. برای اصول اتصال امن، راهنمای اتصال امن PostgreSQL را مطالعه کنید؛ نقش مهاجرت و نقش اجرای روزانه برنامه نباید بی‌دلیل یکسان باشند.
مرحله اول: تغییر افزایشی سازگار
تغییر کوچک و افزایشی را انتخاب کنید و پیش از اجرا اثر قفل و مدت آن را بسنجید. در PostgreSQL رفتار هر دستور به نوع تغییر، اندازه جدول و نسخه بستگی دارد؛ از یک مثال کوچک نتیجه نگیرید که جدول بزرگ هم بی‌اثر تغییر میکند. مستندات ALTER TABLE مرجع شروع بررسی است، نه جای آزمون روی داده نماینده.
-- Isolated demonstration schema only; not a production migration.
ALTER TABLE demo_orders ADD COLUMN display_name text;
-- Keep full_name until old application versions are retired.این مثال فقط قصد سازگاری را نشان میدهد. نام جدول، مجوز، Lock Timeout، کنترل هم‌زمانی و امکان بازاجرا باید در مهاجرت واقعی تعریف شوند. دستور را از مقاله روی دیتابیس اصلی کپی نکنید. نخست ثابت کنید نسخه قدیمی پس از افزودن ستون هنوز کار میکند و نسخه جدید در نبود مقدار تازه رفتار تعریف‌شده دارد.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.