پلنتاسکیل چطور از پستگرس شاردشده بکاپ میگیره
خلاصهٔ کاملتر
تو بلاگ پلنتاسکیل، بن دیکن پشتصحنهٔ بکاپگیری از دیتابیسهای پستگرس شاردشده (پروژهٔ Neki) رو باز کرده. هر ۱۲ ساعت باید کل وضعیت یه دیتابیس شلوغ به یه اسنپشات سازگار و رمزنگاریشده تبدیل شه، اونم بدون اثر روی کوئریهای پروداکشن. به گفتهٔ نویسنده، این همون کاریه که بیشتر مهندسها ترجیح میدن اصلاً بهش فکر نکنن، ولی از داخل ارکستراسیون دقیق زیرساخت ابری میخواد.
روش پایه، ترکیب بکاپ فایلسیستمی با replay کردن WAL آرشیوشدهست. نکتهٔ اصلی اینه که این کار روی پرایمری یا رپلیکاهای ترافیکخور انجام نمیشه، چون IOPS و CPU زیادی میخوره. بهجاش برای هر شارد یه اینستنس EC2 تازه بالا میاد و بکاپ قبلی رو مستقیم از S3 استریم میکنه. نویسنده میگه همین چرخه یه فایدهٔ جانبی مهم داره: هر بار عملاً ثابت میشه بکاپ قبلی واقعاً قابل بازیابیه.
بعدش باید ۱۲ ساعت تغییرات رو جلو برد. کشیدن مستقیم WAL از پرایمری هم سنگینه و هم شدنی نیست، چون WAL مدام با wal-g به S3 آرشیو میشه و همهش روی نود نمیمونه. برای همین رویکرد هیبریدیه: بخش عمدهٔ replay از S3 و فقط چند دقیقهٔ آخر مستقیم از پرایمری. علتش اینه که پستگرس هر سگمنت رو بعد از کامل شدن آرشیو میکنه و archive_timeout پنجدقیقهای یعنی تازهترین تغییرات هنوز به S3 نرسیدن.
سود واقعی تو عددهاست. یه دیتابیس ۳۲ ترابایتی بدون شاردینگ حدود ۴۰ ترابایت جابهجایی لازم داره که با نرخ ۵۰۰ مگابایت بر ثانیه میشه حدود ۲۲ ساعت — یعنی بکاپهای دوبار در روز روی هم میافتن و RPO از دست میره. همون دیتا روی ۸ شارد موازی حدود ۲.۸ ساعت طول میکشه و روی ۳۲ شارد ۴۲ دقیقه. عملاً ۱۰۰ ترابایت روی ۱۰۰ شارد تقریباً همسرعت ۱ ترابایت روی یه شارده.
برای دیتابیس تازه هم اول با pg_basebackup نودهای بکاپ seed میشن، ولی بکاپ ماندگار باز با wal-g ساخته میشه تا فرمت و مسیر ریستور یکی بمونه. جالب اینه که بکاپ فقط برای فاجعه نیست: تغییر سایز دیتابیسهای Metal و جایگزینی نودهای خراب هم از همین بکاپها برای بالا آوردن نودهای جدید استفاده میکنن. سمت MySQL هم منطق مشابهه، با VTBackup و binlog بهجای WAL.
نکات کلیدی:
- بکاپ روی اینستنسهای EC2 موقتی و جدا از پرایمری انجام میشه تا پروداکشن دستنخورده بمونه
- ترکیب بکاپ فایلسیستمی با replay کردن WAL، با منبع هیبریدی S3 و چند دقیقهٔ آخر از پرایمری
- هر چرخه عملاً بازیابیپذیری بکاپ قبلی رو هم تست میکنه
- ۳۲ ترابایت روی ۳۲ شارد در ۴۲ دقیقه؛ نرخ کل بالای ۵۰ گیگابایت بر ثانیه
- همون بکاپها برای resize دیتابیسهای Metal و جایگزینی نود خراب هم به کار میان
