در سخنرانی خود، آندری بورودین به شما خواهد گفت که چگونه تجربه مقیاس گذاری PgBouncer را هنگام طراحی یک مخزن اتصال در نظر گرفته اند. ، چگونه آن را در تولید عرضه کردند. علاوه بر این، ما در مورد عملکردهای pooler صحبت خواهیم کرد که مایلیم در نسخه های جدید ببینیم: برای ما مهم است که نه تنها نیازهای خود را پوشش دهیم، بلکه جامعه کاربران را توسعه دهیم. .
ویدئو:
سلام به همه! اسم من اندرو است.
در Yandex، من در حال توسعه پایگاه داده های منبع باز هستم. و امروز ما یک موضوع در مورد اتصالات استخر اتصال داریم.
اگر می دانید چگونه به روسی با Pooler Connection تماس بگیرید، به من بگویید. من واقعاً می خواهم یک اصطلاح فنی خوب پیدا کنم که باید در ادبیات فنی تثبیت شود.
موضوع کاملاً پیچیده است، زیرا در بسیاری از پایگاه‌های داده، Pooler اتصال داخلی است و شما حتی نیازی به دانستن آن ندارید. برخی از تنظیمات، البته، همه جا هستند، اما در Postgres این کار نمی کند. و به موازات آن (در HighLoad++ 2019) گزارشی توسط نیکولای ساموخوالوف در مورد تنظیم پرس و جو در Postgres وجود دارد. و من درک می کنم که افرادی به اینجا آمده اند که قبلاً درخواست ها را به خوبی پیکربندی کرده اند و اینها افرادی هستند که با مشکلات نادر سیستم مربوط به شبکه و استفاده از منابع روبرو هستند. و در بعضی جاها می تواند بسیار دشوار باشد به این معنا که مشکلات آشکار نیستند.
Yandex دارای Postgres است. بسیاری از سرویس های Yandex در Yandex.Cloud زندگی می کنند. و ما چندین پتابایت داده داریم که حداقل یک میلیون درخواست در ثانیه در Postgres ایجاد می کند.
و ما یک خوشه نسبتاً معمولی برای همه سرویس ها ارائه می دهیم - این گره اصلی اصلی گره است، دو کپی معمولی (همگام و ناهمزمان)، پشتیبان گیری، مقیاس بندی درخواست های خواندن روی ماکت.
هر گره خوشه ای Postgres است که علاوه بر Postgres و سیستم های مانیتورینگ، یک Pooler اتصال نیز روی آن نصب شده است. استخر اتصال برای حصار کشی و برای هدف اصلی آن استفاده می شود.
هدف اصلی یک استخر اتصال چیست؟
Postgres یک مدل فرآیند را برای کار با پایگاه داده اتخاذ می کند. این بدان معنی است که یک اتصال یک فرآیند است، یک Backend Postgres. و تعداد زیادی کش مختلف در این باطن وجود دارد که ساخت آنها برای اتصالات مختلف بسیار گران است.
همچنین در کد Postgres آرایه ای به نام procArray وجود دارد. این شامل داده های اساسی در مورد اتصالات شبکه است. و تقریباً همه الگوریتم‌های پردازش procArray دارای پیچیدگی خطی هستند، آنها از طریق کل آرایه اتصالات شبکه اجرا می‌شوند. این یک چرخه بسیار سریع است، اما با اتصالات شبکه ورودی بیشتر، همه چیز کمی گران تر می شود. و هنگامی که همه چیز کمی گران تر می شود، در نهایت برای تعداد زیادی از اتصالات شبکه هزینه بسیار بالایی را پرداخت می کنید.
3 رویکرد ممکن وجود دارد:
- در سمت برنامه.
- در سمت پایگاه داده.
- و بین، یعنی تمام ترکیبات ممکن.
متأسفانه، Pooler داخلی در حال حاضر در حال توسعه است. دوستان در PostgreSQL Professional بیشتر این کار را انجام می دهند. پیش بینی اینکه چه زمانی ظاهر می شود دشوار است. و در واقع دو راه حل برای انتخاب معمار داریم. اینها استخر سمت برنامه و استخر پروکسی هستند.
استخر سمت برنامه ساده ترین راه است. و تقریباً همه درایورهای سرویس گیرنده راهی را به شما ارائه می دهند: میلیون ها اتصال خود را در کد به عنوان ده ها اتصال به پایگاه داده نشان دهید.
مشکلی در این واقعیت وجود دارد که در یک نقطه خاص که می خواهید باطن را مقیاس کنید، می خواهید آن را در بسیاری از ماشین های مجازی مستقر کنید.
سپس شما هنوز متوجه می شوید که چندین منطقه در دسترس بیشتر، چندین مرکز داده دارید. و رویکرد ادغام سمت مشتری به اعداد بزرگ منجر می شود. بزرگ ها حدود 10 اتصال هستند. این لبه ای است که می تواند به خوبی کار کند.
اگر در مورد پراکسی poolers صحبت کنیم، آنگاه دو pooler وجود دارند که می توانند کارهای زیادی انجام دهند. آنها نه تنها پولدار هستند. آنها pooler + عملکرد جالب تر هستند. این и .
اما، متأسفانه، همه به این قابلیت اضافی نیاز ندارند. و منجر به این واقعیت می شود که poolers فقط از ادغام جلسه پشتیبانی می کند، یعنی یک مشتری ورودی، یک مشتری خروجی به پایگاه داده.
این برای وظایف ما خیلی مناسب نیست، بنابراین ما از PgBouncer استفاده می‌کنیم که ادغام تراکنش‌ها را پیاده‌سازی می‌کند، یعنی اتصالات سرور فقط برای مدت تراکنش به اتصالات مشتری نگاشت می‌شوند.
و در بار ما - درست است. اما چندین مشکل وجود دارد.
مشکلات زمانی شروع می شوند که می خواهید یک جلسه را تشخیص دهید، زیرا همه اتصالات ورودی محلی هستند. همه با Loopback آمدند و به نوعی ردیابی جلسه دشوار می شود.
البته می توانید از application_name_add_host استفاده کنید. این روش جانبی Bouncer برای افزودن آدرس IP به application_name است. اما application_name توسط یک اتصال اضافی تنظیم می شود.
در این نمودار، جایی که خط زرد درخواست های واقعی است، و در آن خط آبی، درخواست هایی است که به پایگاه داده پرواز می کنند. و این تفاوت دقیقاً تنظیمات application_name است که فقط برای ردیابی لازم است اما اصلا رایگان نیست.
علاوه بر این، Bouncer نمی تواند یک استخر، یعنی تعداد اتصالات پایگاه داده به ازای هر کاربر، در هر پایگاه داده را محدود کند.
این به چه چیزی منجر می شود؟ شما یک سرویس لود شده دارید که به زبان C ++ نوشته شده است و در جایی نزدیک یک سرویس کوچک روی یک گره که هیچ مشکلی با پایه ندارد، اما درایور آن دیوانه می شود. 20 اتصال را باز می کند و بقیه چیزها منتظر خواهند ماند. حتی کد شما درست است.
البته، ما یک پچ کوچک برای Bouncer نوشتیم که این تنظیمات را اضافه کرد، یعنی مشتریان را به استخر محدود کرد.
انجام این کار در سمت Postgres امکان پذیر است، یعنی نقش های موجود در پایگاه داده را به تعداد اتصالات محدود کنید.
اما پس از آن شما توانایی درک اینکه چرا هیچ اتصالی به سرور ندارید را از دست می دهید. PgBouncer یک خطای اتصال ایجاد نمی کند، همیشه همان اطلاعات را برمی گرداند. و نمی توانید بفهمید: شاید رمز عبور شما تغییر کرده است، شاید پایگاه داده به تازگی از بین رفته است، شاید مشکلی وجود دارد. اما هیچ تشخیصی وجود ندارد. اگر جلسه را نتوان برقرار کرد، نمی‌دانید چرا نمی‌توان آن را انجام داد.
در یک نقطه خاص، به نمودارهای برنامه نگاه می کنید و می بینید که برنامه کار نمی کند.
به بالا نگاه کنید و ببینید که Bouncer تک رشته ای است. این یک نقطه عطف در زندگی خدمات است. می‌دانید که در یک سال و نیم در حال آماده‌سازی مقیاس‌سازی پایگاه‌داده بودید، و باید مقیاس‌های جمع‌کننده را افزایش دهید.
ما به این نتیجه رسیده ایم که به PgBouncer های بیشتری نیاز داریم.
Bouncer کمی وصله شده است.
و آنها آن را طوری ساختند که با استفاده مجدد از پورت TCP می توان چندین Bouncer را افزایش داد. و در حال حاضر سیستم عامل به طور خودکار اتصالات TCP ورودی را بین آنها توسط round-robin'om منتقل می کند.
این برای کلاینت‌ها شفاف است، یعنی به نظر می‌رسد که شما یک Bouncer دارید، اما اتصالات بی‌کار بین Bouncerهای در حال اجرا تکه‌تکه شده‌اید.
و در برخی موارد، ممکن است متوجه شوید که این 3 Bouncer هر کدام 100٪ هسته خود را می خورند. شما به تعداد زیادی Bouncer نیاز دارید. چرا؟
چون TLS دارید. شما یک اتصال رمزگذاری شده دارید. و اگر Postgres را با و بدون TLS محک بزنید، خواهید دید که تعداد اتصالات برقرار شده تقریباً دو مرتبه با رمزگذاری فعال کاهش می یابد، زیرا دست دادن TLS منابع CPU را مصرف می کند.
و در قسمت بالا، می توانید تعداد زیادی توابع رمزنگاری را مشاهده کنید که در طول موجی از اتصالات ورودی اجرا می شوند. از آنجایی که اصلی ما می تواند بین مناطق در دسترس جابجا شود، موج اتصالات ورودی یک وضعیت نسبتا معمولی است. یعنی به دلایلی، اولیه قدیمی در دسترس نبود، کل بار به مرکز داده دیگری ارسال شد. همه آنها می آیند تا به TLS سلام کنند.
و تعداد زیادی از دست دادن های TLS ممکن است قبلاً به Bouncer سلام نکنند، اما گلوی او را فشار دهند. موجی از اتصالات دریافتی ممکن است به دلیل مهلت زمانی قطع شود. اگر بدون عقب نشینی نمایی دوباره به پایه امتحان کنید، آنها بارها و بارها در یک موج منسجم برنخواهند گشت.
در اینجا یک مثال از 16 PgBouncer است که 16 هسته را در 100٪ بارگذاری می کند.
ما به PgBouncer آبشاری رسیدیم. این بهترین پیکربندی است که می توانیم در بار Bouncer خود به دست آوریم. Bouncer های خارجی ما برای دست دادن TCP و Bouncer های داخلی برای ادغام واقعی استفاده می کنند تا اتصالات خارجی را تا حد زیادی تکه تکه نکنند.
در این پیکربندی، راه اندازی مجدد نرم امکان پذیر است. می توانید تمام این 18 Bouncer را یکی یکی مجدداً راه اندازی کنید. اما حفظ چنین پیکربندی بسیار دشوار است. مدیران سیستم، DevOps و افرادی که واقعاً مسئول این سرور هستند، از این طرح چندان راضی نخواهند بود.
به نظر می رسد که همه پیشرفت های ما می توانند در منبع باز تبلیغ شوند، اما Bouncer خیلی خوب پشتیبانی نمی کند. به عنوان مثال، توانایی اجرای چندین PgBouncer در یک پورت یک ماه پیش متعهد شد. درخواست کشش با این ویژگی چند سال پیش بود.
یا یک مثال دیگر در Postgres، می‌توانید یک درخواست در حال اجرا را با ارسال راز به یک اتصال دیگر بدون احراز هویت اضافی لغو کنید. اما برخی از مشتریان به سادگی یک TCP-reset ارسال می کنند، یعنی اتصال شبکه را قطع می کنند. Bouncer با این چه خواهد کرد؟ او هیچ کاری نخواهد کرد. به اجرای درخواست ادامه خواهد داد. اگر تعداد زیادی اتصال دریافت کرده اید که پایه را با درخواست های کوچک ایجاد کرده اند، پس قطع اتصال از Bouncer کافی نخواهد بود، شما هنوز باید درخواست هایی را که در پایگاه داده در حال اجرا هستند تکمیل کنید.
این وصله شده است و مشکل هنوز در بالادست Bouncer ادغام نشده است.
و بنابراین ما به این نتیجه رسیدیم که ما به پولر اتصال خود نیاز داریم که توسعه یافته، وصله می شود، که در آن امکان رفع سریع مشکلات وجود دارد و البته باید چند رشته ای باشد.
ما multithreading را به عنوان وظیفه اصلی تعیین کردیم. ما باید بتوانیم موج اتصالات TLS ورودی را به خوبی مدیریت کنیم.
برای انجام این کار، ما مجبور شدیم یک کتابخانه جداگانه به نام Machinarium ایجاد کنیم که برای توصیف حالت های ماشین یک اتصال شبکه به عنوان یک کد سریال طراحی شده است. اگر به کد منبع libpq نگاه کنید، تماس‌های بسیار پیچیده‌ای را خواهید دید که می‌توانند نتیجه را به شما برگردانند و بگویند: «کمی بعد با من تماس بگیرید. در حال حاضر IO دارم، اما وقتی IO می گذرد، پردازنده را بارگذاری می کنم. و این یک طرح چند سطحی است. تعامل شبکه معمولاً توسط یک ماشین حالت توصیف می شود. بسیاری از قوانین مانند "اگر قبلاً یک هدر بسته با اندازه N دریافت کردم، اکنون منتظر N بایت هستم"، "اگر یک بسته SYNC ارسال کردم، اکنون منتظر بسته ای با فراداده نتیجه هستم." به نظر می رسد یک کد ضد شهودی نسبتاً دشوار است، گویی که ماز به یک اسکن خطی تبدیل شده است. ما آن را طوری ساختیم که به جای یک ماشین حالت، برنامه نویس مسیر تعامل اصلی را در قالب کد دستوری معمولی توصیف می کند. فقط در این کد ضروری، باید مکان‌هایی را وارد کنید که توالی اجرا باید با انتظار برای داده‌ها از شبکه قطع شود، و متن اجرا را به کوروتین دیگری (رشته سبز) منتقل کنید. این روش شبیه به این است که ما بیشترین مورد انتظار را در پیچ و خم در یک ردیف می نویسیم و سپس شاخه هایی را به آن اضافه می کنیم.
در نتیجه، ما یک رشته داریم که باعث می‌شود یک TCP بپذیرد و یک اتصال TPC را به بسیاری از کارگران ارسال کند.
در این حالت، هر اتصال کلاینت همیشه روی یک پردازنده اجرا می شود. و این به شما این امکان را می دهد که آن را کش پسند کنید.
و علاوه بر این، ما مجموعه بسته های کوچک را در یک بسته بزرگ به منظور تخلیه پشته TCP سیستم کمی بهبود بخشیده ایم.
علاوه بر این، ما ادغام تراکنش‌ها را بهبود بخشیده‌ایم به این معنا که Odyssey در صورت پیکربندی، می‌تواند CANCEL و ROLLBACK را در صورت خرابی اتصال شبکه ارسال کند، یعنی اگر کسی منتظر درخواست نباشد، Odyssey به پایگاه داده می‌گوید تلاشی برای انجام آن نکند. درخواستی که می تواند منابع گرانبها را هدر دهد.
و در صورت امکان، ما اتصالات را به همان مشتری حفظ می کنیم. با این کار نیازی به نصب مجدد application_name_add_host نیست. در صورت امکان، تنظیم مجدد پارامترهای مورد نیاز برای تشخیص نداریم.
ما در راستای منافع Yandex.Cloud کار می کنیم. و اگر از PostgreSQL مدیریت شده استفاده می کنید و یک مخزن اتصال نصب کرده اید، می توانید همانندسازی منطقی را به سمت بیرون ایجاد کنید، یعنی در صورت تمایل ما را با استفاده از تکرار منطقی ترک کنید. جست و خیز خارج از جریان تکرار منطقی نمی دهد.
این نمونه ای از راه اندازی تکرار منطقی است.
علاوه بر این، ما از تکثیر فیزیکی به بیرون پشتیبانی می کنیم. البته در Cloud غیرممکن است، زیرا در این صورت خوشه اطلاعات زیادی در مورد خودش به شما می دهد. اما در نصب شما، اگر نیاز به تکرار فیزیکی از طریق اتصال pool در Odyssey دارید، این امکان وجود دارد.
Odyssey دارای نظارت کاملاً سازگار با PgBouncer است. ما یک کنسول داریم که تقریباً همه دستورات یکسان را اجرا می کند. اگر چیزی کم است، یک درخواست کشش یا حداقل مشکلی در GitHub ارسال کنید، دستورات لازم را تکمیل خواهیم کرد. اما ما در حال حاضر عملکرد اصلی کنسول PgBouncer را داریم.
و البته در فوروارد کردن خطا داریم. ما خطای گزارش شده توسط پایگاه را برمی گردانیم. شما اطلاعاتی را دریافت خواهید کرد که چرا در پایگاه نیستید، نه فقط اینکه در آن پایگاه نیستید.
در صورتی که نیاز به سازگاری 100% با PgBouncer داشته باشید، این ویژگی غیرفعال است. ما می‌توانیم مثل Bouncer رفتار کنیم، فقط در هر صورت.
توسعه
چند کلمه در مورد کد منبع Odyssey.
به عنوان مثال، دستورات "مکث / از سرگیری" وجود دارد. آنها معمولا برای به روز رسانی پایگاه داده استفاده می شوند. اگر نیاز به ارتقای Postgres دارید، می‌توانید آن را در مخزن اتصال متوقف کنید، pg_upgrade را انجام دهید و سپس از سر بگیرید. و از سمت کلاینت، به نظر می رسد که پایگاه داده در حال کند شدن است. این قابلیت توسط افرادی از جامعه به ما ارائه شد. او هنوز نمرده است، اما به زودی همه چیز درست خواهد شد. (از قبل مرده)
- قبلا مرده
علاوه بر این، یکی از ویژگی های جدید در PgBouncer پشتیبانی از SCRAM Authentication است که توسط شخصی که در Yandex.Cloud کار نمی کند نیز برای ما آورده شده است. هر دو عملکرد پیچیده و مهم هستند.
بنابراین، من می خواهم به شما بگویم Odyssey از چه چیزی ساخته شده است، در صورتی که شما هم اکنون می خواهید کد بنویسید.
شما پایه اصلی Odyssey را دارید که بر دو کتابخانه اصلی متکی است. کتابخانه Kiwi پیاده سازی پروتکل پیام Postgres است. یعنی پروتو 3 بومی Postgres پیام های استانداردی است که فرانت اند و بک اند می توانند مبادله کنند. آنها در کتابخانه کیوی اجرا می شوند.
کتابخانه Machinarium یک کتابخانه اجرای رشته است. قطعه کوچکی از این Machinarium در اسمبلر نوشته شده است. اما نگران نباشید، تنها 15 خط وجود دارد.
معماری اودیسه یک ماشین اصلی در حال اجرا کوروتین ها وجود دارد. این دستگاه پذیرش اتصالات TCP ورودی و توزیع بین کارگران را پیاده سازی می کند.
در یک کارگر، یک کنترل کننده برای چندین مشتری می تواند کار کند. و همچنین در موضوع اصلی، کنسول و پردازش وظایف کرون برای حذف اتصالاتی که دیگر در استخر مورد نیاز نیستند در حال چرخش هستند.
Odyssey با استفاده از مجموعه تست استاندارد Postgres آزمایش می شود. ما فقط چک نصب را از طریق Bouncer اجرا می کنیم و از طریق Odyssey، یک div null دریافت می کنیم. چندین تست مربوط به قالب بندی تاریخ وجود دارد که دقیقاً در Bouncer و Odyssey با شکست مواجه می شوند.
علاوه بر این، درایورهای زیادی وجود دارند که تست های مخصوص به خود را دارند. و ما از تست های آنها برای آزمایش اودیسه استفاده می کنیم.
همچنین، به دلیل پیکربندی آبشاری ما، باید بسته‌های مختلفی را آزمایش کنیم: Postgres + Odyssey، PgBouncer + Odyssey، Odyssey + Odyssey تا مطمئن شویم که اگر Odyssey در هر یک از قسمت‌های آبشار باشد، همچنان همانطور که انتظار می‌رود کار می‌کند. .
شن کش
ما از اودیسه در تولید استفاده می کنیم. و منصفانه نخواهد بود اگر بگویم همه چیز فقط کار می کند. نه، یعنی بله، اما نه همیشه. به عنوان مثال، در تولید همه چیز فقط کار کرد، سپس دوستان ما از PostgreSQL Professional آمدند و گفتند که ما نشت حافظه داریم. آنها واقعاً بودند، ما آنها را تعمیر کردیم. اما ساده بود.
سپس متوجه شدیم که مخزن اتصال دارای اتصالات TLS ورودی و اتصالات TLS خروجی است. و اتصالات به گواهی مشتری و گواهی سرور نیاز دارند.
گواهی‌های سرور Bouncer و Odyssey توسط pcache بازخوانی می‌شوند، اما گواهی‌های کلاینت نیازی به بازخوانی از pcache ندارند، زیرا Odyssey مقیاس‌پذیر ما در نهایت بر عملکرد سیستم در خواندن این گواهی استوار است. این برای ما تعجب آور بود، زیرا او بلافاصله استراحت نکرد. ابتدا به صورت خطی مقیاس شد و پس از 20 اتصال همزمان ورودی، این مشکل خود را نشان داد.
Pluggable Authentication Method امکان احراز هویت با ابزارهای داخلی lunux است. در PgBouncer به گونه ای پیاده سازی می شود که یک رشته مجزا در انتظار پاسخ از PAM است و یک رشته اصلی PgBouncer وجود دارد که به اتصال فعلی سرویس می دهد و می تواند از آنها بخواهد که در رشته PAM زندگی کنند.
ما به یک دلیل ساده این را اجرا نکردیم. ما جریان های زیادی داریم. چرا ما به اون احتیاج داریم؟
در نتیجه، این می تواند مشکلاتی را ایجاد کند که اگر احراز هویت PAM و غیر PAM دارید، موج بزرگی از احراز هویت PAM می تواند به طور قابل توجهی احراز هویت غیر PAM را به تاخیر بیندازد. این یکی از مواردی است که ما آن را اصلاح نکرده ایم. اما اگر می خواهید آن را برطرف کنید، می توانید این کار را انجام دهید.
راک دیگر با این واقعیت بود که ما یک رشته داریم که همه اتصالات ورودی را می پذیرد. و سپس آنها به استخر کارگران منتقل می شوند، جایی که دست دادن TLS انجام می شود.
در نتیجه، اگر یک موج منسجم از 20 اتصال شبکه داشته باشید، همه آنها پذیرفته می شوند. و در سمت مشتری، libpq شروع به گزارش وقفه های زمانی می کند. به طور پیش فرض، در آنجا 000 ثانیه است.
اگر همه آنها نتوانند همزمان وارد پایگاه شوند، پس نمی توانند وارد پایگاه شوند، زیرا همه اینها را می توان با تلاش مجدد غیر نمایی پوشش داد.
ما در نهایت طرح PgBouncer را در اینجا کپی کردیم تا تعداد اتصالات TCP را که می پذیریم کاهش دهیم.
اگر دیدیم که کانکشن می پذیریم اما در نهایت وقت دست دادن ندارند، آنها را در یک صف قرار می دهیم تا منابع CPU را مصرف نکنند. این منجر به این واقعیت می شود که ممکن است برای همه اتصالاتی که وارد شده اند، یک دست دادن همزمان انجام نشود. اما حداقل یک نفر وارد پایگاه داده می شود، حتی اگر بار به اندازه کافی قوی باشد.
نقشه راه
دوست دارید در آینده در Odyssey چه چیزی را ببینید؟ چه چیزی برای توسعه خود آماده ایم و چه انتظاراتی از جامعه داریم؟
برای آگوست 2019.
نقشه راه اودیسه در ماه آگوست به این شکل بود:
- ما احراز هویت SCRAM و PAM را می‌خواستیم.
- می‌خواستیم درخواست‌های خواندن را به حالت آماده‌باش منتقل کنیم.
- من می خواهم به صورت آنلاین راه اندازی مجدد شود.
- و قابلیت مکث در سرور.
نیمی از این نقشه راه انجام شده است و نه توسط ما. و این خوب است. پس بیایید در مورد آنچه باقی مانده بحث کنیم و موارد بیشتری را اضافه کنیم.
? ما کپی هایی داریم که بدون انجام درخواست ها، به سادگی هوا را گرم می کنند. ما به آنها برای ارائه Failover و switchover نیاز داریم. در صورت بروز مشکل در یکی از مراکز داده، می خواهم آنها را با چند کار مفید مشغول کنم. زیرا ما نمی‌توانیم همان پردازنده‌های مرکزی، همان حافظه را به روشی متفاوت پیکربندی کنیم، زیرا در غیر این صورت تکرار کار نخواهد کرد.
اصولاً در Postgres با شروع از 10 می توان session_attrs را هنگام اتصال مشخص کرد. می‌توانید همه میزبان‌های پایگاه داده را در اتصال فهرست کنید و بگویید چرا به پایگاه داده می‌روید: فقط نوشتن یا خواندن. و خود راننده اولین میزبانی را در لیست انتخاب می کند که بیشتر دوست دارد، که الزامات session_attrs را برآورده می کند.
اما مشکل این روش این است که تاخیر تکرار را کنترل نمی کند. ممکن است نوعی ماکت داشته باشید که زمان غیرقابل قبولی برای خدمت شما پشت سر گذاشته باشد. به منظور اجرای کامل درخواست‌های خواندن روی یک ماکت، در واقع، ما باید در Odyssey از توانایی کار نکردن در زمانی که خواندن غیرممکن است پشتیبانی کنیم.
Odyssey باید هر از چند گاهی به پایگاه داده برود و فاصله replication از اولیه را بپرسد. و اگر به حد مجاز رسیده است، درخواست های جدید را وارد پایگاه داده ندهید، به مشتری بگویید که باید دوباره اتصالات را شروع کنید و احتمالاً میزبان دیگری را برای اجرای درخواست ها انتخاب کنید. این به پایگاه داده اجازه می دهد تا به سرعت تأخیر تکرار را بازیابی کند و دوباره برای پاسخگویی با یک پرس و جو بازگردد.
نام بردن تاریخ های اجرا مشکل است، زیرا متن باز است. اما، امیدوارم، نه 2,5 سال مانند همکاران PgBouncer. این ویژگی است که من دوست دارم در اودیسه ببینم.
. اکنون می توانید یک بیانیه آماده به دو صورت ایجاد کنید. ابتدا می توانید یک دستور SQL به نام "prepared" را اجرا کنید. برای درک این دستور SQL، باید یاد بگیریم که چگونه SQL را در سمت Bouncer درک کنیم. این امر بیش از حد است زیرا ما به تجزیه کننده کامل نیاز داریم. ما نمی توانیم هر دستور SQL را تجزیه کنیم.
اما یک بیانیه آماده در سطح پروتکل پیام در proto3 وجود دارد. و این جایی است که اطلاعاتی که بیانیه آماده شده در حال ایجاد است به شکل ساختاریافته می آید. و ما می‌توانیم از این درک حمایت کنیم که در برخی از اتصالات سرور، کلاینت درخواست ایجاد دستورات آماده شده را دارد. و حتی اگر تراکنش بسته شود، باز هم باید سرور و کلاینت را متصل نگه داریم.
اما در اینجا یک اختلاف در گفتگو ایجاد می شود، زیرا شخصی می گوید که شما باید بفهمید مشتری کدام عبارات آماده شده را ایجاد کرده است و اتصال سرور را بین همه کلاینت هایی که این اتصال سرور را ایجاد کرده اند به اشتراک بگذارید، یعنی چه کسی چنین بیانیه آماده شده ای را ایجاد کرده است.
آندرس فروند گفت که اگر مشتری به شما مراجعه کرد که قبلاً چنین بیانیه آماده شده ای را در اتصال سرور دیگری ایجاد کرده بود، آن را برای او ایجاد کنید. اما به نظر می رسد اجرای کوئری ها در پایگاه داده به جای کلاینت کمی اشتباه باشد، اما از دیدگاه توسعه دهنده ای که پروتکل تعامل با پایگاه داده را می نویسد، اگر به سادگی یک اتصال شبکه به او داده شود، راحت خواهد بود. که چنین درخواست آماده ای دارد.
و یک ویژگی دیگر که باید پیاده سازی کنیم. ما اکنون مانیتورینگ سازگار با PgBouncer داریم. می توانیم میانگین زمان اجرای پرس و جو را برگردانیم. اما میانگین زمان میانگین دمای بیمارستان است: کسی سرد است، کسی گرم است - به طور متوسط همه سالم هستند. این درست نیست.
ما باید از صدک ها پشتیبانی کنیم، که نشان می دهد درخواست های کندی وجود دارد که منابع را مصرف می کند و نظارت را قابل قبول تر می کند.
مهمتر از همه، من نسخه 1.0 را می خواهم (نسخه 1.1 قبلا منتشر شده است). واقعیت این است که اکنون Odyssey در نسخه 1.0rc، یعنی کاندید انتشار است. و تمام Rake که لیست کردم دقیقا با همین نسخه درست شد به جز نشت حافظه.
نسخه 1.0 چه معنایی برای ما خواهد داشت؟ ما در حال پخش ادیسه به پایگاه های خود هستیم. در حال حاضر در پایگاه داده ما در حال اجرا است، اما زمانی که به 1 درخواست در ثانیه رسید، می توان گفت که این یک نسخه انتشار است و این نسخه ای است که می توان آن را 000 نامید.
چندین نفر در جامعه درخواست مکث و SCRAM بیشتر در نسخه 1.0 کرده اند. اما این بدان معنی است که ما باید نسخه بعدی را برای تولید عرضه کنیم، زیرا نه SCRAM و نه مکث هنوز ادغام نشده اند. اما، به احتمال زیاد، این مشکل نسبتاً سریع حل خواهد شد.
منتظر درخواست کشش شما هستم و همچنین می‌خواهم بشنوم که چه مشکلاتی با Bouncer دارید. بیایید در مورد آنها بحث کنیم. شاید بتوانیم برخی از توابع مورد نیاز شما را پیاده سازی کنیم.
این قسمت من را به پایان می رساند، من می خواهم از شما بشنوم. متشکرم!
پرسش
اگر من application_name خود را قرار دهم، آیا به درستی پرتاب می شود، از جمله در ادغام تراکنش ها در Odyssey؟
Odyssey یا Bouncer؟
در اودیسه. جسور پرتاب می شود.
ما یک مجموعه درست می کنیم.
و اگر اتصال واقعی من روی اتصالات دیگر پرش کند، آیا منتقل می شود؟
ما مجموعه ای از تمام پارامترهای لیست شده را خواهیم ساخت. نمی توانم بگویم application_name در این لیست است یا خیر. گویا او را آنجا دیده است. ما همه پارامترهای مشابه را تنظیم می کنیم. با یک درخواست، مجموعه تمام کارهایی را که در هنگام راه اندازی توسط مشتری نصب شده است انجام می دهد.
با تشکر از آندری برای گزارش! گزارش خوب! خوشحالم که Odyssey هر دقیقه سریعتر و سریعتر پیشرفت می کند. من دوست دارم همین را ادامه دهم. ما قبلاً از شما خواسته‌ایم که یک اتصال چند منبع داده داشته باشید تا Odyssey بتواند همزمان به پایگاه‌های داده مختلف، یعنی Slave master متصل شود و پس از یک Failover به طور خودکار به Master جدید متصل شود.
بله، به نظر می رسد که من آن بحث را به یاد می آورم. اکنون چندین انبار وجود دارد. اما هیچ جابجایی بین آنها وجود ندارد. از طرف ما، باید از سرور پرس و جو کنیم که هنوز زنده است و بفهمیم که یک failover رخ داده است، که pg_recovery را فراخوانی می کند. من یک راه استاندارد برای درک اینکه ما به استاد نیامده ایم دارم. و باید به نحوی از اشتباهات متوجه شویم یا چگونه؟ یعنی ایده جالب است، در حال بحث است. نظرات بیشتری بنویسید اگر دست‌های کاری دارید که C را می‌دانند، این به طور کلی فوق‌العاده است.
موضوع مقیاس‌گذاری در بین کپی‌ها نیز برای ما جالب است، زیرا می‌خواهیم پذیرش کلاسترهای تکراری را تا حد امکان برای توسعه‌دهندگان برنامه ساده کنیم. اما در اینجا من نظرات بیشتری می خواهم، یعنی چگونه این کار را انجام دهیم، چگونه آن را خوب انجام دهیم.
سوال هم در مورد ماکت هاست. معلوم می شود که شما یک استاد و چندین ماکت دارید. و واضح است که برای اتصالات کمتر به ماکت مراجعه می کنند، زیرا ممکن است با هم تفاوت داشته باشند. شما گفتید که تفاوت داده ها ممکن است به حدی باشد که کسب و کار شما راضی نمی شود و تا زمانی که تکرار نشود به آنجا نخواهید رفت. در عین حال، اگر برای مدت طولانی به آنجا نرفتید و سپس شروع به رفتن کردید، داده های مورد نیاز فوراً در دسترس نخواهند بود. یعنی اگر مدام سراغ مستر برویم، کش آنجا گرم می شود و کش کمی از ماکت عقب است.
بله این درست است. هیچ بلوک داده ای در pcache مورد نظر شما وجود نخواهد داشت، در کش واقعی هیچ اطلاعاتی در مورد جداول مورد نظر شما وجود نخواهد داشت، هیچ پرس و جو تجزیه شده در پلان ها وجود نخواهد داشت، اصلاً هیچ چیز.
و وقتی نوعی خوشه دارید، و یک ماکت جدید را در آنجا اضافه می کنید، در حالی که شروع می شود، همه چیز در آن بد است، یعنی حافظه پنهان خود را افزایش می دهد.
من ایده گرفتم روش صحیح این است که ابتدا درصد کمی از پرس و جوها را روی ماکت اجرا کنید، که باعث گرم شدن حافظه پنهان می شود. به طور کلی، ما یک شرط داریم که بیش از 10 ثانیه از استاد عقب نمانیم. و این شرط نباید در یک موج باشد، بلکه برای برخی از مراجعین هموار باشد.
بله افزایش وزن
این ایده خوبی است. اما ابتدا باید این خاموش شدن را اجرا کنید. ابتدا باید خاموش شویم و سپس به نحوه روشن شدن فکر خواهیم کرد. این یک ویژگی عالی برای روشن کردن روان است.
nginx این گزینه را دارد slowly start در خوشه برای سرور. و او به تدریج بار را جمع می کند.
بله، ایده خوبی است، وقتی به آن رسیدیم آن را امتحان خواهیم کرد.
منبع: www.habr.com