پیشنهاد می‌کنم متن گزارش ابتدای سال 2019 توسط آندری بورودین «پشتیبان‌گیری با WAL-G. در سال 2019 چیست؟» را بخوانید.
سلام به همه! نام من آندری بورودین است. من یک توسعه دهنده در Yandex هستم. من از سال 2016 به PostgreSQL علاقه مند شدم، بعد از اینکه با توسعه دهندگان صحبت کردم و آنها گفتند که همه چیز ساده است - شما کد منبع را بگیرید و آن را بسازید، و همه چیز درست می شود. و از آن زمان من نمی توانم متوقف شوم - انواع چیزهای مختلف را می نویسم.
یکی از چیزهایی که من روی آن کار می کنم یک سیستم پشتیبان است. . به طور کلی، در Yandex ما برای مدت طولانی روی سیستم های پشتیبان در PostgreSQL کار می کنیم. و شما می توانید در اینترنت مجموعه ای از شش گزارش در مورد نحوه ساخت سیستم های پشتیبان پیدا کنید. و هر سال آنها کمی تکامل می یابند، کمی توسعه می یابند و قابل اعتمادتر می شوند.
اما امروز گزارش نه تنها در مورد آنچه ما انجام داده ایم، بلکه در مورد اینکه چقدر ساده و چیست است. چند نفر از شما قبلا گزارش های من در مورد WAL-G را تماشا کرده اید؟ خوب است که تعداد کمی از مردم تماشا نکردند، زیرا من از ساده ترین چیز شروع می کنم.
اگر ناگهان یک خوشه PostgreSQL دارید، و من فکر می‌کنم همه چند تا از آنها را به همراه دارند، و ناگهان هنوز سیستم پشتیبان‌گیری وجود ندارد، باید هر فضای ذخیره‌سازی S3 یا فضای ذخیره‌سازی سازگار با Google Cloud را دریافت کنید.
به عنوان مثال، می توانید به غرفه ما بیایید و یک کد تبلیغاتی برای Yandex Object Storage، که با S3 سازگار است، بگیرید.
سپس یک Bucket ایجاد کنید. این فقط یک ظرف برای اطلاعات است.
یک کاربر سرویس ایجاد کنید.
یک کلید دسترسی برای کاربر سرویس ایجاد کنید: aws-s3-key.
آخرین نسخه پایدار WAL-G را دانلود کنید.
پیش از انتشار ما چه تفاوتی با نسخه های منتشر شده دارد؟ اغلب از من خواسته می شود که زودتر آزاد شوم. و اگر برای مدت کافی مثلاً یک ماه باگی در نسخه وجود نداشته باشد، آن را آزاد می کنم. این نسخه از نوامبر است. و این بدان معناست که هر ماه نوعی باگ پیدا میکنیم، معمولاً در عملکرد غیر بحرانی، اما هنوز نسخه‌ای منتشر نکرده‌ایم. نسخه قبلی فقط نوامبر است. هیچ باگ شناخته شده ای در آن وجود ندارد، یعنی با پیشرفت پروژه، باگ هایی اضافه شدند.
هنگامی که WAL-G را دانلود کردید، می‌توانید یک فرمان ساده «لیست پشتیبان» را اجرا کنید و متغیرهای محیط را منتقل کنید. و به Object Storage متصل می شود و به شما می گوید که چه بک آپ هایی دارید. در ابتدا، البته، شما نباید پشتیبان داشته باشید. هدف این اسلاید نشان دادن این است که همه چیز بسیار ساده است. این یک دستور کنسول است که متغیرهای محیطی را می پذیرد و دستورات فرعی را اجرا می کند.
پس از این، می توانید اولین نسخه پشتیبان خود را تهیه کنید. در WAL-G بگویید «backup-push» و در WAL-G مکان pgdata خوشه خود را مشخص کنید. و به احتمال زیاد، PostgreSQL به شما خواهد گفت، اگر قبلاً یک سیستم پشتیبان ندارید، باید "حالت آرشیو" را فعال کنید.
این بدان معناست که شما باید به تنظیمات بروید و "archive_mode = on" را روشن کنید و "archive_command" را اضافه کنید، که در WAL-G نیز یک دستور فرعی است. اما به دلایلی مردم اغلب از نوار اسکریپت در مورد این موضوع استفاده می کنند و آن را در اطراف WAL-G قرار می دهند. لطفا این کار را نکنید از عملکرد موجود در WAL-G استفاده کنید. اگر چیزی را از دست دادید، به آن بنویسید . WAL-G فرض می کند که این تنها برنامه ای است که در archive_command اجرا می شود.
ما از WAL-G عمدتاً برای ایجاد یک خوشه دسترسی بالا در مدیریت پایگاه داده Yandex استفاده می کنیم.
و معمولا در توپولوژی یک Master و چندین تکرار استفاده می شود. در همان زمان، یک نسخه پشتیبان در ذخیره سازی اشیاء Yandex ایجاد می کند.
رایج ترین سناریوها ایجاد کپی از یک خوشه با استفاده از بازیابی نقطه در زمان است. اما در این مورد، عملکرد سیستم پشتیبان برای ما چندان مهم نیست. فقط باید یک خوشه جدید از پشتیبان آپلود کنیم.
به طور معمول، هنگام اضافه کردن یک گره جدید، به عملکرد سیستم پشتیبان نیاز داریم. چرا مهم است؟ معمولاً افراد یک گره جدید به یک خوشه اضافه می کنند زیرا خوشه موجود نمی تواند بار خواندن را مدیریت کند. آنها باید یک ماکت جدید اضافه کنند. اگر بار را از pg_basebackup به Master اضافه کنیم، ممکن است Master سقوط کند. بنابراین، برای ما بسیار مهم بود که بتوانیم به سرعت یک گره جدید از آرشیو آپلود کنیم و حداقل بار را روی Master ایجاد کنیم.
و یک وضعیت مشابه دیگر. این نیاز به راه اندازی مجدد Master قدیمی پس از تعویض Cluster Master از مرکز داده است که اتصال با آن قطع شده است.
- در نتیجه، هنگام فرمول‌بندی الزامات سیستم کپی، متوجه شدیم که pg_basebackup هنگام کار در فضای ابری برای ما مناسب نیست.
- می خواستیم بتوانیم داده هایمان را فشرده کنیم. اما تقریباً هر سیستم پشتیبان به غیر از آنچه در جعبه موجود است، فشرده سازی داده ها را فراهم می کند.
- ما می خواستیم همه چیز را موازی کنیم زیرا یک کاربر در فضای ابری تعداد زیادی هسته پردازنده می خرد. اما اگر در برخی عملیات موازی سازی نداشته باشیم، تعداد زیادی از هسته ها بی فایده می شوند.
- ما به رمزگذاری نیاز داریم زیرا اغلب داده ها متعلق به ما نیستند و نمی توانند در متن واضح ذخیره شوند. به هر حال، کمک ما به WAL-G با رمزگذاری آغاز شد. رمزگذاری را در WAL-G تکمیل کردیم، پس از آن از ما پرسیدند: "شاید یکی از ما پروژه را توسعه دهد؟" و از آن زمان من بیش از یک سال است که با WAL-G کار می کنم.
- ما همچنین به کنترل منابع نیاز داشتیم، زیرا به مرور زمان با استفاده از ابر متوجه شدیم که گاهی اوقات افراد در شب بار خواربار مهمی دارند و نمی توان با این بار مداخله کرد. به همین دلیل است که کنترل منابع را اضافه کردیم.
- و همچنین فهرست بندی و مدیریت.
- و تایید.
ما ابزارهای مختلف زیادی را بررسی کردیم. خوشبختانه، ما انتخاب زیادی در PostgreSQL داریم. و همه جا چیزی را از دست می دادیم، برخی یک عملکرد کوچک، برخی یک ویژگی کوچک.
و با بررسی سیستم های موجود، به این نتیجه رسیدیم که WAL-G را توسعه خواهیم داد. آن زمان یک پروژه جدید بود. تأثیرگذاری بر توسعه به سمت زیرساخت ابری سیستم پشتیبان بسیار آسان بود.
ایدئولوژی اصلی که ما به آن پایبند هستیم این است که WAL-G باید به سادگی یک بالالایکا باشد.
WAL-G دارای 4 فرمان است. این:
WAL-PUSH - شفت را بایگانی کنید.
WAL-FETCH - یک شفت بگیرید.
BACKUP-PUSH - یک نسخه پشتیبان تهیه کنید.
BACKUP-FETCH - از سیستم پشتیبان تهیه کنید.
در واقع، WAL-G همچنین مدیریت این پشتیبان‌ها را دارد، یعنی فهرست کردن و حذف سوابق و نسخه‌های پشتیبان در تاریخ که در حال حاضر دیگر مورد نیاز نیستند.
یکی از توابع مهم برای ما عملکرد ایجاد کپی دلتا است.
کپی دلتا به این معنی است که ما یک نسخه پشتیبان کامل از کل کلاستر ایجاد نمی کنیم، بلکه فقط صفحات تغییر یافته فایل های تغییر یافته در خوشه را ایجاد می کنیم. به نظر می رسد که از نظر عملکردی این بسیار شبیه به توانایی بازیابی با استفاده از WAL است. اما می توانیم یک پشتیبان دلتا تک رشته ای WAL را به صورت موازی جمع آوری کنیم. بر این اساس، زمانی که ما یک نسخه پشتیبان اولیه را در روز شنبه تهیه می کنیم، روزانه نسخه پشتیبان دلتا تهیه می کنیم و در روز پنجشنبه شکست می خوریم، پس باید 4 نسخه پشتیبان دلتا و 10 ساعت WAL را جمع آوری کنیم. تقریباً همان زمان طول می کشد زیرا پشتیبان های دلتا به صورت موازی می چرخند.
دلتاهای مبتنی بر LSN - این بدان معنی است که هنگام ایجاد یک نسخه پشتیبان، باید هر صفحه را ترکیب کرده و LSN آن را با LSN نسخه پشتیبان قبلی بررسی کنیم تا بفهمیم که تغییر کرده است. هر صفحه ای که به طور بالقوه می تواند حاوی داده های تغییر یافته باشد باید در نسخه پشتیبان دلتا وجود داشته باشد.
همانطور که گفتم، توجه زیادی به موازی سازی شد.
اما API آرشیو در PostgreSQL سازگار است. PostgreSQL یک فایل WAL را بایگانی می کند و هنگام بازیابی یک فایل WAL درخواست می کند. اما زمانی که پایگاه داده با استفاده از دستور "WAL-FETCH" یک فایل WAL را درخواست می کند، دستور "WAL-PREFETCH" را فراخوانی می کنیم که 8 فایل بعدی را برای واکشی داده ها از شی ذخیره به صورت موازی آماده می کند.
و وقتی پایگاه داده از ما می خواهد که یک فایل را بایگانی کنیم، به archive_status نگاه می کنیم و می بینیم که آیا فایل های WAL دیگری وجود دارد یا خیر. و همچنین سعی می کنیم WAL را به صورت موازی دانلود کنیم. این افزایش عملکرد قابل توجهی را فراهم می کند و به طور قابل توجهی فاصله در تعداد WAL های بایگانی نشده را کاهش می دهد. بسیاری از توسعه دهندگان سیستم های پشتیبان بر این باورند که این یک سیستم بسیار خطرناک است زیرا ما به دانش خود در مورد کدهای داخلی متکی هستیم که API PostgreSQL نیست. PostgreSQL وجود پوشه archive_status را برای ما تضمین نمی کند و معنایی، وجود سیگنال های آمادگی برای فایل های WAL را در آنجا تضمین نمی کند. با این وجود، ما در حال مطالعه کد منبع هستیم، می بینیم که اینطور است و سعی می کنیم از آن سوء استفاده کنیم. و ما مسیری را که PostgreSQL در آن توسعه می‌یابد کنترل میکنیم؛ اگر این مکانیسم به طور ناگهانی خراب شود، استفاده از آن را متوقف میکنیم.
در شکل خالص خود، WAL delta مبتنی بر LSN نیاز به خواندن هر فایل خوشه‌ای دارد که زمان حالت آن در سیستم فایل نسبت به نسخه پشتیبان قبلی تغییر کرده است. ما برای مدت طولانی، تقریبا یک سال با این زندگی کردیم. و در نهایت به این نتیجه رسیدیم که دلتاهای WAL داریم.
این بدان معنی است که هر بار که WAL را روی Master بایگانی می کنیم، نه تنها آن را فشرده، رمزگذاری و به شبکه ارسال می کنیم، بلکه همزمان آن را نیز می خوانیم. سوابق موجود در آن را تحلیل و مطالعه می کنیم. ما درک می کنیم که کدام بلوک ها تغییر کرده اند و فایل های دلتا را جمع آوری می کنیم.
یک فایل دلتا محدوده خاصی از فایل های WAL را توصیف می کند، اطلاعاتی را در مورد اینکه کدام بلوک ها در این محدوده WAL تغییر کرده اند را توصیف می کند. و سپس این فایل های دلتا نیز بایگانی می شوند.
در اینجا ما با این واقعیت روبرو هستیم که همه چیز را خیلی سریع موازی کردیم، اما نمی توانیم یک تاریخ متوالی را به طور موازی بخوانیم، زیرا در یک بخش خاص ممکن است با پایان رکورد WAL قبلی روبرو شویم که هنوز چیزی برای ارتباط با آن نداریم، زیرا خواندن موازی منجر به این شد که ابتدا آینده ای را تحلیل کنیم که هنوز گذشته ای ندارد.
در نتیجه، مجبور شدیم قطعات نامفهوم را در فایل های _delta_partial قرار دهیم. در نتیجه، وقتی به گذشته برمی گردیم، قطعات رکورد WAL را به یکی می چسبانیم، پس از آن آن را تجزیه می کنیم و متوجه می شویم که چه چیزی در آن تغییر کرده است.
اگر در تاریخچه تجزیه شفت ما حداقل یک نقطه وجود داشته باشد که ما درک نکنیم چه اتفاقی می افتد، بر این اساس، در طول نسخه پشتیبان بعدی مجبور خواهیم شد دوباره کل خوشه را بخوانیم، همانطور که با یک LSN معمولی انجام دادیم. دلتای مبتنی بر
در نتیجه، همه رنج‌های ما به این واقعیت منجر شد که کتابخانه تجزیه WAL-G را منبع باز کردیم. تا اونجایی که من میدونم هنوز کسی ازش استفاده نمیکنه ولی اگه کسی خواست بنویسه و استفاده کنه در دسترس عمومه. (لینک به روز شد )
در نتیجه، تمام جریان های اطلاعاتی کاملاً پیچیده به نظر می رسند. استاد ما شفت را بایگانی می کند و فایل های دلتا را بایگانی می کند. و ماکتی که نسخه پشتیبان تهیه می کند باید فایل های دلتا را در مدت زمانی که بین نسخه های پشتیبان سپری شده است دریافت کند. در این مورد، بخش‌هایی از تاریخچه باید به صورت انبوه اضافه و تجزیه شوند، زیرا کل تاریخچه در بخش‌های بزرگ قرار نمی‌گیرد. و تنها پس از این، ماکت می تواند یک نسخه پشتیبان کامل دلتا را بایگانی کند.
در نمودارها همه چیز بسیار ساده تر به نظر می رسد. این یک دانلود از یکی از خوشه های واقعی ما است. ما مبتنی بر LSN داریم که در یک روز ساخته شده است. و می بینیم که بک آپ دلتا مبتنی بر LSN از سه صبح تا پنج صبح در حال اجرا بود. این بار در تعداد هسته های پردازنده است. WAL-delta در اینجا حدود 20 دقیقه وقت ما را گرفت، یعنی به طور قابل توجهی سریعتر شد، اما در همان زمان تبادل شدیدتری از طریق شبکه وجود داشت.
از آنجایی که ما اطلاعاتی در مورد اینکه کدام بلوک ها و در چه زمانی در تاریخچه پایگاه داده تغییر کرده اند، فراتر رفتیم و تصمیم گرفتیم که عملکرد را یکپارچه کنیم - یک پسوند PostgreSQL به نام "pg_prefaulter"
این بدان معناست که هنگامی که پایگاه آماده به کار دستور بازیابی را اجرا می کند، به WAL-G می گوید که فایل WAL بعدی را واکشی کند. ما می‌دانیم که فرآیند بازیابی WAL در آینده نزدیک به کدام بلوک‌های داده دسترسی خواهد داشت و عملیات خواندن را در این بلوک‌ها آغاز میکنیم. این کار به منظور افزایش عملکرد کنترلرهای SSD انجام شد. زیرا رول WAL به صفحه ای می رسد که باید تغییر کند. این صفحه روی دیسک است و در کش صفحه نیست. و او به طور همزمان منتظر رسیدن این صفحه خواهد بود. اما در نزدیکی WAL-G است که می‌داند در چند صد مگابایت بعدی WAL به صفحات خاصی نیاز خواهیم داشت و در همان زمان شروع به گرم کردن آنها می‌کند. چندین دسترسی به دیسک را آغاز می کند تا به صورت موازی اجرا شوند. این به خوبی روی درایوهای SSD کار می کند، اما، متأسفانه، مطلقاً برای هارد دیسک قابل اجرا نیست، زیرا ما فقط با درخواست های خود با آن تداخل می کنیم.
این همان چیزی است که اکنون در کد موجود است.
ویژگی هایی وجود دارد که می خواهیم اضافه کنیم.
این تصویر نشان می دهد که WAL-delta زمان نسبتاً کوتاهی دارد. و این خواندن تغییراتی است که در طول روز در پایگاه داده رخ داده است. ما می‌توانیم WAL-delta را نه تنها در شب انجام دهیم، زیرا دیگر منبع بار قابل توجهی نیست. ما می توانیم WAL-delta را هر دقیقه بخوانیم زیرا ارزان است. در یک دقیقه می توانیم تمام تغییراتی که در خوشه رخ داده است را اسکن کنیم. و این را می توان "WAL-delta فوری" نامید.
نکته این است که وقتی خوشه را بازیابی می کنیم، تعداد داستان هایی را که باید به صورت متوالی جمع آوری کنیم کاهش می دهیم. یعنی مقدار WAL که PostgreSQL رول می کند باید کاهش یابد، زیرا زمان قابل توجهی می برد.
اما این همه ماجرا نیست. اگر می دانیم که برخی از بلوک ها تا حد سازگاری پشتیبان تغییر می کند، نمی توانیم آن را در گذشته تغییر دهیم. یعنی اکنون ما بهینه سازی فایل به فایل ارسال WAL-delta را داریم. این به این معنی است که اگر، برای مثال، در روز سه‌شنبه، یک جدول به طور کامل حذف شد یا برخی از فایل‌ها به طور کامل از جدول حذف شدند، پس وقتی delta رول در روز دوشنبه و شنبه بازیابی شد، ما حتی این داده‌ها را ایجاد نمی‌کنیم.
ما می خواهیم این فناوری را به سطح صفحه گسترش دهیم. یعنی اگر بخشی از فایل در روز دوشنبه تغییر کند، اما روز چهارشنبه بازنویسی شود، پس هنگام بازگرداندن به نقطه ای در روز پنجشنبه، نیازی نیست که چند نسخه اول صفحات را روی دیسک بنویسیم.
اما این هنوز ایده ای است که به طور فعال در درون ما مورد بحث قرار می گیرد، اما هنوز به کد نرسیده است.
ما می خواهیم یک ویژگی دیگر در WAL-G ایجاد کنیم. ما می‌خواهیم آن را توسعه‌پذیر کنیم، زیرا نیاز به پشتیبانی از پایگاه‌های داده مختلف داریم و می‌خواهیم بتوانیم مدیریت پشتیبان‌گیری را به همان شیوه انجام دهیم. اما مشکل این است که APIهای MySQL کاملاً متفاوت هستند. در MySQL، PITR بر اساس گزارش فیزیکی WAL نیست، بلکه بر اساس binlog است. و ما یک سیستم بایگانی در MySQL نداریم که به سیستم خارجی بگوید که این binlog تمام شده است و باید بایگانی شود. ما باید در جایی با پایگاه داده بایستیم و بررسی کنیم که آیا چیزی آماده است؟
و به همین ترتیب، در طول بازیابی MySQL، هیچ دستور بازیابی وجود ندارد که بتواند به سیستم بگوید که من به فلان فایل نیاز دارم. قبل از شروع بازسازی کلاستر خود، باید بدانید که به چه فایل هایی نیاز دارید. شما خودتان باید حدس بزنید به چه فایل هایی نیاز دارید. اما ممکن است بتوان این مشکلات را به نحوی دور زد. (توضیح: MySQL قبلاً پشتیبانی می شود)
در گزارش می خواستم در مورد مواردی که WAL-G برای شما مناسب نیست صحبت کنم.
اگر نسخه همگام ندارید، WAL-G تضمین نمی کند که آخرین بخش حفظ شود. و اگر آرشیو کردن از چند بخش آخر تاریخ عقب باشد، این یک خطر است. اگر ماکت همزمان وجود نداشته باشد، استفاده از WAL-G را توصیه نمی کنم. با این حال، عمدتاً برای نصب ابری طراحی شده است، که به یک راه حل با قابلیت دسترسی بالا با یک کپی همزمان، که مسئول ایمنی آخرین بایت های متعهد است، دلالت دارد.
من اغلب افرادی را می بینم که سعی می کنند WAL-G و WAL-E را همزمان اجرا کنند. ما از سازگاری به عقب پشتیبانی می کنیم به این معنا که WAL-G می تواند یک فایل را از WAL-E بازیابی کند و می تواند یک نسخه پشتیبان تهیه شده در WAL-E را بازیابی کند. اما از آنجایی که هر دوی این سیستم ها از wal-push موازی استفاده می کنند، شروع به سرقت فایل ها از یکدیگر می کنند. اگر آن را در WAL-G درست کنیم، همچنان در WAL-E باقی خواهد ماند. در WAL-E، به وضعیت آرشیو نگاه می کند، فایل های تمام شده را می بیند و آنها را بایگانی می کند، در حالی که سایر سیستم ها به سادگی نمی دانند که این فایل WAL وجود داشته است، زیرا PostgreSQL برای بار دوم سعی نمی کند آن را بایگانی کند.
ما در اینجا در سمت WAL-G قرار است چه چیزی را برطرف کنیم؟ ما به PostgreSQL اطلاع نمی دهیم که این فایل به صورت موازی منتقل شده است و وقتی PostgreSQL از ما می خواهد آن را بایگانی کنیم، از قبل می دانیم که چنین فایلی با این حالت زمان و با این md5 قبلاً بایگانی شده است و ما به سادگی می گوییم PostgreSQL - خوب، همه چیز بدون انجام کاری آماده است.
اما بعید است که این مشکل در سمت WAL-E برطرف شود، بنابراین در حال حاضر ایجاد یک دستور بایگانی که فایل را در WAL-G و WAL-E بایگانی کند غیرممکن است.
علاوه بر این مواردی وجود دارد که WAL-G در حال حاضر برای شما مناسب نیست، اما ما قطعا آن را برطرف خواهیم کرد.
اولاً، ما در حال حاضر تأیید پشتیبان داخلی نداریم. ما در حین پشتیبان گیری یا بازیابی تأییدی نداریم. البته این در فضای ابری پیاده سازی می شود. اما این به سادگی با بررسی قبلی، به سادگی با بازیابی خوشه اجرا می شود. من می خواهم این قابلیت را به کاربران بدهم. اما با تأیید، فرض می‌کنم که در WAL-G میتوان خوشه را بازیابی کرد و آن را راه‌اندازی کرد و آزمایش‌های دود را اجرا کرد: pg_dumpall به /dev/null و تأیید صحت نمایه amcheck.
در حال حاضر در WAL-G هیچ راهی برای به تعویق انداختن یک نسخه پشتیبان از WAL وجود ندارد. یعنی ما از یک پنجره پشتیبانی می کنیم. به عنوان مثال، ذخیره هفت روز گذشته، ذخیره ده نسخه پشتیبان آخر، ذخیره سه نسخه پشتیبان کامل آخر. اغلب مردم می آیند و می گویند: "ما به یک نسخه پشتیبان از اتفاقات سال نو نیاز داریم و می خواهیم آن را برای همیشه نگه داریم." WAL-G هنوز نمی تواند این کار را انجام دهد. (توجه - این قبلاً رفع شده است. ادامه مطلب - گزینه Backup-mark in )
و ما هنگام اعتبارسنجی PITR، جمع‌های چک و بررسی یکپارچگی برای همه بخش‌های شفت نداریم.
از همه اینها من یک پروژه برای Google Summer of Code جمع کردم. اگر دانش‌آموزان باهوشی را می‌شناسید که دوست دارند در Go چیزی بنویسند و با حرف G از یک شرکت چندین هزار دلار دریافت کنند، پروژه ما را به آنها توصیه کنید. من به عنوان یک مربی برای این پروژه عمل خواهم کرد، آنها می توانند این کار را انجام دهند. اگر دانش آموز نباشد، تابستان آن را می گیرم و خودم انجام می دهم.
و خیلی مشکلات ریز دیگر داریم که کم کم داریم روی آنها کار می کنیم. و اتفاقات بسیار عجیبی رخ می دهد.
به عنوان مثال، اگر به WAL-G یک نسخه پشتیبان خالی بدهید، به سادگی سقوط می کند. به عنوان مثال، اگر به او بگویید که باید از یک پوشه خالی نسخه پشتیبان تهیه کند. فایل pg_control وجود نخواهد داشت. و او فکر می کند که چیزی را نمی فهمد. در تئوری، در این حالت باید یک پیام عادی برای کاربر بنویسید تا نحوه استفاده از ابزار را برای او توضیح دهید. اما این حتی یک ویژگی برنامه نویسی نیست، بلکه ویژگی یک زبان خوب و قابل فهم است.
ما نمی دانیم چگونه پشتیبان گیری آفلاین انجام دهیم. اگر پایگاه داده دروغ می گوید، نمی توانیم از آن نسخه پشتیبان تهیه کنیم. اما همه چیز در اینجا بسیار ساده است. ما پشتیبان گیری توسط LSN زمانی که شروع شد فراخوانی می کنیم. LSN پایه زیرین باید از فایل کنترل خوانده شود. و این یک ویژگی غیر قابل تحقق است. بسیاری از سیستم های پشتیبان می توانند از یک پایگاه داده زیربنایی پشتیبان تهیه کنند. و راحت است.
ما در حال حاضر نمی توانیم کمبود فضای پشتیبان را به درستی مدیریت کنیم. چون معمولا در خانه با پشتیبان های بزرگ کار می کنیم. و به آن نرسیدند. اما اگر کسی می‌خواهد در Go برنامه‌نویسی کند، مدیریت خطاهای خارج از فضا را به باکت اضافه کنید. من قطعا به درخواست کشش نگاه خواهم کرد.
و اصلی‌ترین چیزی که ما را نگران می‌کند این است که می‌خواهیم تا آنجا که ممکن است آزمایش‌های یکپارچه‌سازی داکر را انجام دهیم که سناریوهای مختلف را بررسی کند. در حال حاضر ما فقط سناریوهای اساسی را آزمایش می کنیم. در هر commit، اما ما می‌خواهیم تمام قابلیت‌هایی را که پشتیبانی میکنیم، commit-by-commit بررسی کنیم. به طور خاص، به عنوان مثال، ما پشتیبانی کافی برای PostgreSQL 9.4-9.5 خواهیم داشت. ما از آنها پشتیبانی می کنیم زیرا انجمن از PostgreSQL پشتیبانی می کند، اما commit-by-commit را بررسی نمی کنیم تا مطمئن شویم همه چیز خراب نیست. و به نظر من این یک خطر نسبتاً جدی است.
ما WAL-G را روی بیش از هزار کلاستر در مدیریت پایگاه داده Yandex داریم. و هر روز از چند صد ترابایت از داده ها نسخه پشتیبان تهیه می کند.
ما TODO زیادی در کد خود داریم. اگر می خواهید برنامه ریزی کنید، بیایید، ما منتظر درخواست های کشش هستیم، منتظر سوالات هستیم.
پرسش
عصر بخیر! متشکرم! حدس من این است که اگر از WAL-delta استفاده می کنید، احتمالاً به شدت به نوشتن تمام صفحه متکی هستید. و اگر چنین است، آیا شما آزمایشاتی را انجام داده اید؟ نمودار زیبایی نشون دادی اگر FPW خاموش باشد چقدر زیباتر می شود؟
نوشتن تمام صفحه برای ما فعال است، ما سعی نکرده ایم آن را غیرفعال کنیم. یعنی من به عنوان یک توسعه دهنده سعی نکرده ام آن را خاموش کنم. مدیران سیستمی که تحقیق کرده اند احتمالا در مورد این موضوع تحقیق کرده اند. اما ما به FPW نیاز داریم. تقریباً هیچ کس آن را غیرفعال نمی کند، زیرا در غیر این صورت نمی توان از یک نسخه پشتیبان تهیه کرد.
با تشکر از گزارش! دو تا سوال دارم اولین سوال این است که چه اتفاقی برای tablespace ها خواهد افتاد؟
ما منتظر درخواست کشش هستیم. پایگاه داده های ما روی دیسک های SSD و NMVE زندگی می کنند و ما واقعاً به این ویژگی نیاز نداریم. من حاضر نیستم در حال حاضر وقت جدی را برای انجام خوب آن صرف کنم. من صمیمانه از این حمایت می کنم. افرادی هستند که از آن حمایت کردند، اما به نحوی که مناسب خودشان است از آن حمایت کردند. آنها یک چنگال درست کردند، اما درخواست های کششی را انجام نمی دهند. (اضافه شده در نسخه 0.2.13)
و سوال دوم. شما در همان ابتدا گفتید که WAL-G فرض می کند که به تنهایی کار می کند و نیازی به لفاف نیست. من خودم از لفاف استفاده می کنم. چرا نباید از آنها استفاده کرد؟
ما می خواهیم به سادگی یک بالالایکا باشد. این بدان معنی است که شما به هیچ چیز به جز بالالایکا نیاز ندارید. ما می خواهیم سیستم ساده باشد. اگر عملکردی دارید که باید در یک اسکریپت انجام دهید، بیایید و به ما بگویید - ما آن را در Go انجام خواهیم داد.
عصر بخیر! با تشکر از گزارش! نتوانستیم WAL-G را با رمزگشایی GPG کار کند. به طور معمول رمزگذاری می کند، اما نمی خواهد رمزگشایی کند. آیا چیزی است که برای ما کارساز نبود؟ وضعیت ناامید کننده است.
یک مشکل در GitHub ایجاد کنید و بیایید آن را کشف کنیم.
یعنی با این برخورد نکردی؟
یک ویژگی در گزارش خطا وجود دارد که وقتی WAL-G متوجه نمی شود چه نوع فایلی است، می پرسد: "شاید رمزگذاری شده است؟" شاید مشکل اصلا رمزگذاری نیست. من می‌خواهم ثبت‌نام در این موضوع را بهبود بخشم. او باید آن را رمزگشایی کند. ما در حال حاضر روی این موضوع کار می کنیم به این معنا که واقعاً از نحوه سازماندهی سیستم دریافت کلیدهای عمومی و خصوصی خوشمان نمی آید. چون ما جی پی جی اکسترنال را صدا می زنیم تا کلیدهایش را به ما بدهد. و سپس این کلیدها را می گیریم و به GPG داخلی منتقل می کنیم که PGP باز است که در داخل WAL-G برای ما کامپایل شده است و در آنجا رمزگذاری می گوییم. در این راستا، ما می خواهیم سیستم را بهبود بخشیم و می خواهیم از رمزگذاری Libsodium (افزوده شده در نسخه 0.2.15) پشتیبانی کنیم. البته، رمزگشایی باید کار کند، بیایید آن را بفهمیم - شما بیشتر از چند کلمه به یک علامت نیاز دارید. می توانید زمانی در اتاق سخنران جمع شوید و به سیستم نگاه کنید. (رمزگذاری PGP بدون GPG خارجی - نسخه 0.2.9)
سلام! با تشکر از گزارش! دو تا سوال دارم من میل عجیبی به انجام pg_basebackup و ورود WAL به دو ارائه دهنده دارم، یعنی می خواهم یک ابری و دیگری را انجام دهم. آیا راهی برای این کار وجود دارد؟
این در حال حاضر وجود ندارد، اما ایده جالبی است.
من فقط به یک ارائه دهنده اعتماد ندارم، می خواهم همان را در دیگری داشته باشم، فقط در صورت امکان.
ایده جالبی است. از نظر فنی، اجرای این امر اصلاً دشوار نیست. برای جلوگیری از گم شدن ایده، می‌توانم از شما بخواهم در GitHub مشکلی ایجاد کنید؟
بله البته
و سپس، وقتی دانش‌آموزان به Google Summer of Code می‌آیند، آنها را به پروژه اضافه میکنیم تا کار بیشتری برای بهره‌گیری بیشتر از آنها وجود داشته باشد.
و سوال دوم. مشکلی در GitHub وجود دارد. فکر کنم قبلا بسته شده در حین بازیابی یک وحشت وجود دارد. و برای شکست آن مجلس جداگانه ای درست کردید. در مسائل درست است. و گزینه ای برای انجام یک محیط متغیر در یک رشته وجود دارد. و به همین دلیل بسیار کند کار می کند. و ما با این مشکل مواجه شدیم و هنوز رفع نشده است.
مشکل این است که به دلایلی ذخیره‌سازی (CEPH) اتصال را بازنشانی می‌کند که با همزمانی بالا به آن می‌رسیم. در این باره چه میتوان کرد؟ منطق امتحان مجدد به این شکل است. در حال تلاش برای دانلود مجدد فایل هستیم. در یک گذر، تعدادی فایل دانلود نشده داشتیم، برای همه کسانی که وارد نشدند، یک فایل دوم درست می کنیم. و تا زمانی که حداقل یک فایل در هر تکرار بارگذاری شود، ما تکرار و تکرار و تکرار می کنیم. ما منطق تلاش مجدد - عقب نشینی نمایی را بهبود بخشیم. اما کاملاً مشخص نیست که با این واقعیت که اتصال به سادگی در سمت سیستم ذخیره سازی قطع می شود، چه باید کرد. یعنی وقتی در یک جریان آپلود می کنیم این ارتباطات را قطع نمی کند. در اینجا چه چیزی را می توانیم بهبود دهیم؟ ما throttling شبکه داریم، می توانیم هر اتصال را با تعداد بایت هایی که ارسال می کند محدود کنیم. در غیر این صورت، نمی‌دانم چگونه با این واقعیت کنار بیایم که ذخیره‌سازی شی به ما امکان دانلود یا دانلود موازی از آن را نمی‌دهد.
SLA وجود ندارد؟ آیا برای آنها نوشته نشده است که چگونه به خود اجازه عذاب می دهند؟
نکته این است که افرادی که این سوال را مطرح می کنند معمولاً صندوق مخصوص خود را دارند. یعنی هیچ کس از Amazon یا Google Cloud یا Yandex Object Storage نمی آید.
شاید این سوال دیگر برای شما نباشد؟
سوال اینجا در این مورد برای چه کسی مهم نیست. اگر ایده ای در مورد نحوه برخورد با این موضوع وجود دارد، بیایید آن را در WAL-G انجام دهیم. اما تا کنون هیچ ایده خوبی در مورد نحوه برخورد با این موضوع ندارم. برخی از Object Storage وجود دارند که پشتیبان‌گیری‌های فهرست را متفاوت پشتیبانی می‌کنند. از آنها می خواهید اشیاء را لیست کنند و آنها پوشه ای را در آنجا اضافه می کنند. WAL-G در این مورد می ترسد - چیزی در اینجا وجود دارد که یک فایل نیست، من نمی توانم آن را بازیابی کنم، به این معنی که نسخه پشتیبان بازیابی نشده است. یعنی در واقع، شما یک خوشه کاملاً بازیابی شده دارید، اما وضعیت اشتباهی را به شما برمی‌گرداند، زیرا Object Storage اطلاعات عجیبی را که کاملاً متوجه نشده بود، برگرداند.
این چیزی است که در ابر ایمیل اتفاق می افتد.
اگر می توانید یک بازتولید بسازید ...
به طور مداوم تکثیر می شود ...
اگر یک بازتولید وجود داشته باشد، پس فکر می‌کنم ما با استراتژی‌های امتحان مجدد آزمایش خواهیم کرد و چگونگی تلاش مجدد را دریابیم و درک کنیم که ابر از ما چه می‌خواهد. شاید روی سه اتصال برای ما پایدار باشد و اتصال را قطع نکند، سپس با دقت به سه اتصال برسیم. زیرا اکنون ما اتصال را خیلی سریع قطع می کنیم، یعنی اگر ریکاوری را با 16 رشته راه اندازی کنیم، پس از اولین تلاش مجدد، 8 رشته، 4 رشته، 2 رشته و یک موضوع وجود خواهد داشت. و سپس فایل را به یک جریان می کشد. اگر مقادیر جادویی وجود داشته باشد مانند 7,5 نخ برای پمپاژ بهترین است، ما روی آنها تمرکز می کنیم و سعی می کنیم 7,5 نخ دیگر بسازیم. در اینجا یک ایده است.
با تشکر از گزارش! یک گردش کار کامل برای کار با WAL-G چگونه است؟ به عنوان مثال، در مورد احمقانه که هیچ دلتای در سراسر صفحات وجود ندارد. و بک آپ اولیه را می گیریم و حذف می کنیم، سپس شفت را بایگانی می کنیم تا در صورت آبی شویم. در اینجا، همانطور که من متوجه شدم، یک خرابی وجود دارد. در برخی مواقع باید از صفحات یک نسخه پشتیبان دلتا تهیه کنید، به عنوان مثال، برخی از فرآیندهای خارجی این کار را انجام می دهد یا چگونه این اتفاق می افتد؟
API پشتیبان دلتا بسیار ساده است. یک عدد وجود دارد - حداکثر گام های دلتا، این چیزی است که به آن می گویند. پیش فرض آن صفر است. این به این معنی است که هر بار که یک Backup-Push انجام می دهید، یک نسخه پشتیبان کامل دانلود می کند. اگر آن را به هر عدد مثبتی، به عنوان مثال، 3 تغییر دهید، دفعه بعد که یک فشار پشتیبان انجام می دهید، به تاریخچه پشتیبان گیری های قبلی نگاه می کند. او می بیند که شما از زنجیره 3 دلتا فراتر نمی روید و یک دلتا می سازد.
یعنی هر وقت WAL-G رو راه اندازی میکنیم سعی میکنه بک آپ کامل بگیره؟
نه، ما WAL-G را اجرا میکنیم، و اگر خط‌مشی‌های شما اجازه می‌دهد، سعی می‌کند یک دلتا ایجاد کند.
به طور کلی، اگر هر بار آن را با صفر اجرا کنید، آیا مانند pg_basebackup عمل می کند؟
نه، همچنان سریعتر اجرا می شود زیرا از فشرده سازی و موازی سازی استفاده می کند. Pg_basebackup شفت را در کنار شما قرار می دهد. WAL-G فرض می کند که بایگانی را پیکربندی کرده اید. و در صورت عدم پیکربندی اخطار می دهد.
Pg_basebackup را می توان بدون شفت اجرا کرد.
بله، در این صورت آنها تقریباً یکسان رفتار خواهند کرد. Pg_basebackup در سیستم فایل کپی می کند. در ضمن، ما یک ویژگی جدید داریم که فراموش کردم به آن اشاره کنم. اکنون می توانیم از pg_basebackup در سیستم فایل پشتیبان تهیه کنیم. من نمی دانم چرا این مورد نیاز است، اما وجود دارد.
به عنوان مثال، در CephFS. همه نمی خواهند Object Storage را پیکربندی کنند.
بله، احتمالاً به همین دلیل است که سؤالی در مورد این ویژگی پرسیده اند تا بتوانیم آن را انجام دهیم. و ما این کار را انجام دادیم.
با تشکر از گزارش! فقط یک سوال در مورد کپی کردن در سیستم فایل وجود دارد. خارج از جعبه، آیا اکنون از کپی کردن در حافظه از راه دور پشتیبانی می کنید، به عنوان مثال، اگر قفسه ای در مرکز داده وجود دارد یا چیز دیگری؟
در این فرمول، این یک سوال دشوار است. بله، ما پشتیبانی می کنیم، اما این قابلیت هنوز در هیچ نسخه ای گنجانده نشده است. یعنی همه نسخه های پیش از انتشار از این پشتیبانی می کنند، اما نسخه های منتشر شده از این پشتیبانی نمی کنند. این قابلیت در نسخه 0.2 اضافه شده است. به محض رفع همه باگ های شناخته شده، قطعا به زودی منتشر خواهد شد. اما در حال حاضر این کار فقط در پیش از انتشار قابل انجام است. دو باگ در نسخه پیش از انتشار وجود دارد. مشکل در بازیابی WAL-E، ما آن را برطرف نکردیم. و در آخرین پیش انتشار، یک اشکال در مورد پشتیبان گیری دلتا اضافه شد. بنابراین به همه توصیه می کنیم از نسخه های منتشر شده استفاده کنند. به محض اینکه دیگر باگ در نسخه پیش از انتشار وجود نداشت، می توان گفت که از Google Cloud، چیزهای سازگار با S3 و ذخیره سازی فایل پشتیبانی می کنیم.
سلام ممنون از گزارش همانطور که متوجه شدم، WAL-G نوعی سیستم متمرکز مانند بارمن نیست؟ آیا قصد دارید در این مسیر حرکت کنید؟
مشکل این است که ما از این مسیر دور شده ایم. WAL-G روی میزبان پایه، روی میزبان خوشه و روی همه میزبان‌های خوشه زندگی می‌کند. وقتی به چند هزار خوشه نقل مکان کردیم، تأسیسات بارمن زیادی داشتیم. و هر بار که چیزی در آنها خراب می شود، مشکل بزرگی است. از آنجایی که آنها نیاز به تعمیر دارند، باید درک کنید که کدام خوشه ها اکنون پشتیبان ندارند. من قصد ندارم WAL-G را در جهت سخت افزار فیزیکی برای سیستم های پشتیبان توسعه دهم. اگر جامعه خواهان عملکردی در اینجا باشد، من اصلاً مشکلی ندارم.
ما تیم هایی داریم که مسئول ذخیره سازی هستند. و ما آنقدر احساس خوبی داریم که این ما نیستیم، که افراد خاصی هستند که فایل های ما را در جایی قرار می دهند که فایل ها امن هستند. آنها انواع کدنویسی هوشمندانه را در آنجا انجام می دهند تا از دست دادن تعداد معینی از فایل ها مقاومت کنند. آنها مسئول پهنای باند شبکه هستند. هنگامی که یک بارمن دارید، ممکن است ناگهان متوجه شوید که پایگاه های داده کوچک با ترافیک زیاد روی همان سرور جمع شده اند. به نظر می رسد فضای زیادی روی آن دارید، اما به دلایلی همه چیز از طریق شبکه جا نمی شود. ممکن است برعکس شود. شبکه های زیادی در آنجا وجود دارد، هسته های پردازنده وجود دارد، اما دیسکی در اینجا وجود ندارد. و ما از این نیاز به فریبکاری خسته شدیم و به سمت این واقعیت رفتیم که ذخیره سازی داده ها یک سرویس جداگانه است که افراد خاص جداگانه مسئول آن هستند.
PS نسخه جدید منتشر شد ، که در آن می توانید از فایل پیکربندی .walg.json استفاده کنید که به طور پیش فرض در فهرست اصلی postgres قرار دارد. می توانید اسکریپت های bash را رها کنید. مثال walg.json در این شماره است
ویدئو:
منبع: www.habr.com