محتوای آموزشی وبلاگ نت‌آرام
فضای سرور کم شده و در پوشه پایگاه داده چند فایل با نام‌هایی مانند
mysql-bin.000001 می‌بینید. وسوسه می‌شوید فایل‌های قدیمی را مستقیم پاک کنید، اما این فایل‌ها ممکن است برای نسخه‌های تکثیرشده پایگاه داده یا بازیابی تغییرات پس از بکاپ لازم باشند. حذف اشتباه می‌تواند فضای دیسک را آزاد کند ولی در عوض امکان بازیابی اطلاعات را از بین ببرد.در این راهنما یاد می‌گیریم چه چیزی را اندازه بگیریم، وابستگی‌ها را چطور پیدا کنیم و اگر واقعاً بخشی از لاگ دیگر لازم نبود، مرز حذف را چگونه با روش خود پایگاه داده تعیین کنیم. مثال‌ها عمدتاً بر پایه MySQL هستند؛ MariaDB و نسخه‌های مختلف نام دستورها، مجوزها و گزینه‌های متفاوتی دارند. اگر مدیر پایگاه داده نیستید، تغییر را به مسئول مجاز بسپارید.
binlog چیست و چرا ممکن است زیاد شود؟
Binary log یا binlog دنباله‌ای از رویدادهای تغییر داده است. یک سرور replica ممکن است برای دریافت تغییرات به آن وابسته باشد. همچنین در برخی برنامه‌های پشتیبان‌گیری، پس از بازگرداندن بکاپ پایه، از رویدادهای لازم برای رسیدن به زمان موردنظر استفاده می‌شود. پس binlog با یک فایل موقت بی‌اهمیت برابر نیست و خودِ آن هم بدون بکاپ پایه معتبر، یک برنامه بازیابی کامل نیست.
افزایش تعداد تغییرات، نگهداری طولانی یا توقف سازوکار پاک‌سازی می‌تواند مصرف را زیاد کند. ابتدا باید ببینید واقعاً کدام فایل‌ها و کدام سیستم‌فایل پر شده‌اند. اگر دیسک تقریباً پر است، کارهای پرحجم غیرضروری را با نظر مسئول متوقف و برای ایجاد فضای اضطراریِ امن برنامه‌ریزی کنید؛ پاک‌کردن تصادفی فایل‌های دیتابیس می‌تواند وضعیت را بدتر کند.
قدم اول: فضای واقعی و محل پایگاه داده را بشناسید
در لینوکس، با حساب مدیر مجاز برای دیدن فضای مسیر موردنظر، مسیر واقعی را به‌جای مثال قرار دهید:
کد / دستورdf -hT /var/lib/mysql
این فرمان ظرفیت سیستم‌فایل حاوی آن مسیر را نشان می‌دهد. در سرور شما مسیر داده یا binlog ممکن است جای دیگری باشد؛ پیش از نتیجه‌گیری پیکربندی سرویس را بخوانید. اگر دستور می‌گوید مسیر وجود ندارد، از روی نام نمونه پوشه نسازید یا حذف نکنید.
به پایگاه داده با حساب مدیریتی مجاز و روش امن سرویس وارد شوید. مثلاً در بعضی نصب‌های لینوکسی، مدیر می‌تواند
کد / دستورsudo mysql را اجرا کند؛ در نصب‌های دیگر حساب و روش احراز هویت متفاوت است. رمز را در متن دستور، فایل عمومی یا تصویر قرار ندهید. پیش از کار، نوع و نسخه سرور را ببینید:SELECT VERSION();
SHOW VARIABLES LIKE 'log_bin';
دستور اول نسخه را نشان می‌دهد و دومی وضعیت فعال‌بودن ثبت باینری را گزارش می‌کند. اگر خروجی یا دسترسی متفاوت است، از مدیر پایگاه داده کمک بگیرید. سپس، اگر مجوز لازم را دارید، فهرست فایل‌های ثبت‌شده را بخوانید:
کد / دستورSHOW BINARY LOGS;
نام و اندازه هر فایل دیده می‌شود. مجموع تقریبی آن‌ها را با مصرف واقعی دیسک و سایر فایل‌ها مقایسه کنید؛ نام و اندازه به‌تنهایی مشخص نمی‌کند فایل قابل حذف است. اگر این دستور خطا داد، متن آن و نسخه را ثبت کنید و به‌جای حدس، مجوز و فعال‌بودن قابلیت را بررسی کنید.
قدم دوم: نیاز replica و بازیابی را قبل از تعیین مرز بشناسید
فهرست همه replicaها و سامانه‌هایی را که از این منبع تغییر دریافت می‌کنند با مسئول معماری تطبیق دهید. فقط replica متصل و سالم مهم نیست؛ نسخه‌ای که موقتاً خاموش یا عقب‌مانده است نیز ممکن است بعداً به فایل قدیمی نیاز داشته باشد. در نسخه مناسب MySQL، مدیر می‌تواند در هر replica وضعیت را با دستور زیر بخواند:
کد / دستورSHOW REPLICA STATUS\G
این دستور در محیط خط فرمان MySQL برای نمایش خواناتر از
\G استفاده می‌کند. نسخه‌های قدیمی‌تر یا MariaDB ممکن است از نام متفاوت، مانند SHOW SLAVE STATUS\G، استفاده کنند. فیلدهای مربوط به فایل و موقعیت خواندن و اعمال رویدادها، وضعیت اتصال، تأخیر و استفاده از GTID را طبق نسخه و معماری تفسیر کنید. دیدن یک عدد بدون شناخت صف دریافت و اعمال برای تعیین مرز حذف کافی نیست.سپس با مسئول بکاپ روشن کنید قدیمی‌ترین بکاپ پایه قابل بازیابی کدام است و برای بازیابی تا زمان هدف به کدام رویدادها نیاز دارید. سیاست نگهداری قانونی و تجاری، یکپارچگی زنجیره و نتیجه آخرین آزمون بازیابی نیز اهمیت دارند. اگر نمی‌توانید همه مصرف‌کنندگان و بازه بازیابی را مشخص کنید، مرز امن حذف هنوز معلوم نیست.
قدم سوم: تنظیم نگهداری فعلی را بخوانید
در MySQL نسخه‌های پشتیبانی‌کننده می‌توانید مقدار فعلی را ببینید:
کد / دستورSHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW VARIABLES LIKE 'expire_logs_days';
ممکن است یکی از نام‌ها در نسخه شما وجود نداشته باشد یا رفتار آن متفاوت باشد. این پرس‌وجوها فقط مقدار را می‌خوانند. مدت نگهداری مناسب باید فاصله مجاز عقب‌ماندگی replica، برنامه بکاپ و زمان کشف خطا را پوشش دهد. قرار دادن یک عدد خیلی کم صرفاً برای آزادشدن دیسک می‌تواند روز بعد امکان بازیابی یا اتصال replica را از بین ببرد. قبل از تغییر تنظیم پایدار، رفتار نسخه، زمان اعمال و اثر بر همه مصرف‌کنندگان را در محیط آزمایشی بررسی کنید.
قدم چهارم: اگر مرز امن واقعاً مشخص شد
مدیر پایگاه داده باید پس از تطبیق همه replicaها، نسخه‌های پشتیبان و سیاست بازیابی، قدیمی‌ترین فایل موردنیاز را تعیین کند. طبق راهنمای رسمی PURGE در MySQL، دستور زیر فایل‌های قبل از نام تعیین‌شده را حذف می‌کند و خود فایل نام‌برده را نگه می‌دارد:
کد / دستورPURGE BINARY LOGS TO 'mysql-bin.000123';
این نام فقط نمونه است و اجرای آن روی سرور واقعی بدون تعیین مرز همان سرور می‌تواند داده موردنیاز بازیابی یا replica را حذف کند. این عملیات برگشت‌پذیر نیست مگر نسخه معتبر و برنامه بازیابی داشته باشید. برای هر فایل در محدوده، نیاز replicaهای آفلاین، بکاپ و سایر مصرف‌کنندگان را جداگانه بررسی کنید و طبق سیاست سازمان نسخه موردنیاز را نگه دارید. سازنده همچنین درباره اجرای purge در زمان قفل بکاپ هشدار می‌دهد.
از حذف مستقیم با
rm، خالی‌کردن فایل باز، و اجرای دستورهایی که همه binlogها یا وضعیت GTID را بازنشانی می‌کنند خودداری کنید. حذف دستی می‌تواند فهرست داخلی فایل‌ها را با دیسک ناسازگار کند. اگر قبلاً فایل‌ها دستی حذف شده‌اند و دستور خطا می‌دهد، تعمیر فهرست و زنجیره تکثیر کار تخصصی است و باید پس از حفظ شواهد و پشتیبان با مدیر مربوط انجام شود؛ آن را با حدس ویرایش نکنید.پس از اقدام، نتیجه و پیشگیری را بررسی کنید
دوباره
SHOW BINARY LOGS و df -hT را اجرا کنید و فهرست، فضای آزاد و نبود خطای جدید را ببینید. وضعیت همه replicaها را در بازه بعدی و پس از اتصال مجدد نسخه‌های آفلاین بررسی کنید. برنامه بکاپ و توان بازیابی تا زمان هدف را نیز در محیط جداگانه آزمایش کنید. کم‌شدن حجم فایل‌ها به‌تنهایی اثبات سالم‌بودن زنجیره بازیابی نیست.برای جلوگیری از پرشدن دوباره، رشد روزانه را اندازه بگیرید، برای فضای آزاد هشدار بگذارید و سیاست نگهداری متناسب با حداکثر عقب‌ماندگی و برنامه بکاپ تعیین کنید. اگر فایل دیگری عامل اصلی پرشدن دیسک است، سراغ همان علت بروید. راهنمای فایل حذف‌شده‌ای که هنوز فضای لینوکس را گرفته است نیز یکی از علت‌های متفاوت بازنگشتن فضا را توضیح می‌دهد.
مشخصات سرور اختصاصی ایران نت‌آرام و سرور مجازی ایران در صفحه‌های مربوط آمده‌اند. انتخاب ظرفیت بیشتر می‌تواند فرصت بدهد، اما جای تعیین سیاست نگهداری و بازیابی را نمی‌گیرد.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام