از معماری تا پیادهسازی کلاسترهای مقاوم و با دسترسپذیری بالا
PostgreSQL امروزه به یکی از پیشرفتهترین و پرکاربردترین سیستمهای مدیریت پایگاهداده رابطهای متنباز تبدیل شده است. معماری توسعهپذیر (Extensible) این سامانه، امکان افزودن قابلیتهای متنوع از جمله پردازش دادههای مکانی، زمانی، برداری، جستجوی تماممتن و حتی انبارش تحلیلی(OLAP) را فراهم کرده است. به همین دلیل، بسیاری از سازمانها و پلتفرمهای مدرن، PostgreSQL را به عنوان هسته مرکزی زیرساخت داده خود انتخاب میکنند.
با گسترش روزافزون کاربرد PostgreSQL، نیاز به متخصصانی که فراتر از دانش سطحی، به معماری داخلی، بهینهسازی، پشتیبانگیری پیشرفته، replication و High Availability مسلط باشند، به شدت افزایش یافته است. این دوره با هدف پر کردن این شکاف طراحی شده و شرکتکنندگان را از سطح مقدماتی تا توانایی طراحی و مدیریت کلاسترهای PostgreSQL در مقیاس سازمانی ارتقا میدهد.
در این دوره، موضوعات زیر به صورت کاربردی بررسی و مرور خواهند شد :
پیش از هر اقدامی، باید محیطی عملیاتی برای کار با PostgreSQL فراهم کنیم. در این فصل، نصب PostgreSQL روی سیستم عامل لینوکس/ویندوز به صورت گام به گام انجام میشود و انواع ابزارهای اتصال از خط فرمان گرفته تا محیطهای گرافیکی حرفه ای معرفی میگردند. سپس با ایجاد چند دیتابیس نمونه و تولید دادههای آموزشی، عملیات ابتدایی مانند ساخت جدول، ایندکس، دنباله و اسکیما تمرین میشود تا پیش از ورود به مباحث عمیقتر، دست شرکتکنندگان برای کار عملی روی یک دیتابیس واقعی کاملاً باز باشد.
psql به عنوان رابط خط فرمان اصلیpgcli با قابلیت تکمیل خودکار و syntax highlightingبدون شناخت معماری حافظه، فرآیندها و ساختار فایلها، بسیاری از رفتارهای PostgreSQL برای مدیر یک جعبه سیاه باقی میماند. در این بخش، اجزای داخلی موتور PostgreSQL موشکافانه بررسی میشود: از حافظه اشتراکی و محلی گرفته تا فرآیندهای زمینه و نحوه ذخیرهسازی فیزیکی دادهها. مکانیزم MVCC به عنوان قلب PostgreSQL و ابزار VACUUM برای مدیریت نسخههای قدیمی داده ها، به صورت عملی بررسی میشوند.
shared_buffers، wal_buffers، work_mem، maintenance_work_mempostmaster، backend processes، background workers (bgwriter، checkpointer، autovacuum، walwriter)VACUUM، VACUUM FULL، autovacuum، پارامترهای تنظیمییک دیتابیس بدون امنیت، مانند گاوصندوق بدون قفل است. در این فصل، مکانیزم نقشها و کاربران PostgreSQL با جزئیات کامل بررسی میشود و روش پیادهسازی اصل کمترین دسترسی آموزش داده میشود. فایل pg_hba.conf به عنوان دیوار دفاعی در سطح شبکه پیکربندی و روشهای مختلف احراز هویت شامل رمزنگاری ارتباطات با SSL پیادهسازی میگردد.
GRANT، REVOKE)pg_hba.conf: رکوردهای احراز هویت بر اساس آدرس، کاربر، دیتابیسscram-sha-256، md5، trust، peer، certدادهها باید هوشمندانه ذخیره شوند. در این فصل با Tablespace و امکان توزیع اشیاء روی دیسکهای متفاوت آشنا میشویم. جداول سیستمی template0 و template1 و کاربرد آنها در سفارشیسازی دیتابیسهای جدید بررسی میشود. بخش اصلی این فصل، ایندکسهای متنوع PostgreSQL است: از B-tree گرفته تا GiST، GIN، BRIN و SP-GiST. دستور CLUSTER برای مرتبسازی فیزیکی جداول بر اساس ایندکس نیز به عنوان یک تکنیک بهینهسازی پیشرفته آموزش داده میشود.
template0، template1 و نحوه ایجاد دیتابیس سفارشیFILLFACTORCLUSTER و pg_clusterREINDEX، pg_repack و جداول سیستمی مرتبط با ایندکسهاوقتی حجم دادهها از حدی فراتر رود، پارتیشنبندی نه یک انتخاب، بلکه یک ضرورت است. در این فصل، روشهای پارتیشنبندی Range، List و Hash به صورت عملی پیادهسازی میشود. سپس چالشهای مدیریت دستی پارتیشنها بررسی و دو افزونه کلیدی معرفی میگردند: pg_partman برای خودکارسازی چرخه حیات پارتیشنها و pg_cron برای زمانبندی وظایف درون دیتابیس. در انتها، یک سناریوی تمام خودکار برای پارتیشنبندی ماهانه طراحی و اجرا میشود.
PARTITION BY RANGE، LIST، HASHrun_maintenance() و create_parent()در معماریهای مدرن، دادهها به ندرت در یکجا متمرکز هستند. FDW (Foreign Data Wrapper) امکان کوئریزنی شفاف روی منابع خارجی را بدون انتقال فیزیکی دادهها فراهم میکند. در این فصل با postgres_fdw شروع کرده، سپس به اتصال به ClickHouse میپردازیم. یک سناریوی عملی پیادهسازی میشود که در آن کاربران تنها با PostgreSQL کار میکنند، اما کوئریهای تحلیلی به صورت خودکار به ClickHouse ارسال و نتیجه بازگردانده میشود.
postgres_fdwFOREIGN SERVER، USER MAPPING و FOREIGN TABLEclickhouse_fdw کندترین بخش هر برنامه، اغلب دیتابیس آن است. در این کارگاه عملی، زبان مشترک با بهینهساز PostgreSQL یعنی خروجی EXPLAIN خط به خط تفسیر میشود. مفاهیم Cost، Row، Width و انواع Join تحلیل میگردد و دلیل انتخاب پلن اجرایی نامناسب ریشهیابی میشود. با بررسی pg_stats و تأثیر ANALYZE، نقش آمار در بهینهسازی روشن میشود. پارامترهای تنظیمی مؤثر بر بهینهساز نیز مرور و به صورت عملی تغییر داده میشوند.
EXPLAIN و EXPLAIN ANALYZEANALYZE و آمار جدول (pg_stats)random_page_cost، seq_page_cost، effective_cache_size، work_mempg_stat_statementsپیش از هر رخداد ناخوشایندی در حوزه دیتابیس، باید برای آن آماده بود. بکاپ منطقی با ابزارهای بومی PostgreSQL ساده ترین و در دسترسترین روش پشتیبانگیری است. در این فصل با pg_dump، pg_dumpall و pg_restore کار میکنیم و تفاوت فرمتهای خروجی (plain, custom, directory, tar) را بررسی میکنیم. نکات اجرایی در دیتابیسهای بزرگ، مدیریت همزمانی و بازیابی انتخابی نیز آموزش داده میشود.
pg_dump: ساختار و داده، انتخاب اشیاء، فیلتر کردن-Fp (plain)، -Fc (custom)، -Fd (directory)، -Ft (tar)pg_dumpall: پشتیبانگیری از کل کلاستر (نقشها، tablespace)pg_restore: بازیابی از فرمتهای غیر plain و بازیابی موازی--jobsاگر یک DROP TABLE در ساعت ۳ بامداد اجرا شود، چه باید کرد؟ بازیابی به یک زمان خاص (Point-In-Time Recovery) تنها راه بازگشت به لحظه پیش از حادثه است. در این فصل، ساختار و نقش فایلهای WAL (Write-Ahead Log) به طور عمیق بررسی میشود. سپس WAL Archiving فعال شده و یک سناریوی کامل PITR گام به گام اجرا میگردد. بخصوص نحوه بررسی و جستجوی فایلهای WAL با pg_waldump هم آموزش داده می شود که بتوانیم نقطه مناسب برای بازیابی را به صورت دقیق بیابیم.
wal_level، archive_mode، archive_commandrecovery.signal recovery_target_time، recovery_target_lsn، recovery_target_name)برای دیتابیسهای چندترابایتی، بکاپ منطقی کند و ناکارآمد است. و ما نیاز داریم بتوانیم از کل پوشههای اصلی پستگرس، بکاپ بگیریم. در این فصل علاوه بر معرفی اصلی ترین گزینه استاندارد کار با بکاپ های فیزیکی یعنی pg_basebackup، سه ابزار استاندارد و سازمانی پوشش داده میشوند: Barman برای مدیریت ایستگاههای بکاپ، pgBackRest برای بکاپ فشرده و رمزنگاری شده با قابلیت incremental، و WAL-G برای ارسال بکاپ به object storage و بکاپ افزایشی سریع. با تسلط بر این ابزارها، استراتژی پشتیبانگیری در سطح غولهای فناوری پیادهسازی میشود. البته از نسخه ۱۷ پستگرس به بعد، ما بکاپ افزایشی را در خود پستگرس اصلی هم داریم اما کار با این ابزارهای جانبی، معمولا راحتتر و برای کارهای سازمانی، مناسبتر است.
barman backup، barman recover، retention policyیکی از امکانات جذاب پستگرس، امکان دریافت لحظهای تغییرات یک یا چند جدول توسط یک پستگرس راه دور است. در این روش که به تکرار منطقی معروف است، دستورات SQL لازم برای اعمال آن تغییرات، به مشترکین به صورت خودکار توسط پستگرس اصلی یا ناشر تغییرات، ارسال میشود.
در این فصل معماری Publisher/Subscriber بررسی میشود و یک replication منطقی بین دو کلاستر راه اندازی میگردد. میآموزیم چطور تنها زیرمجموعه ای از جداول را replicate کنیم و تأخیر replication را مانیتور کنیم. این روش همچنین برای مهاجرت بلادرنگ دادهها به سامانههای دیگر کاربرد فراوان دارد.
CREATE PUBLICATIONCREATE SUBSCRIPTIONpg_stat_subscription و pg_stat_replicationپیشنیاز هر معماری High Availability و Load Balancing، رپلیکیشن فیزیکی است. در این فصل دو روش سنتی و مدرن مقایسه میشود: لاگشیپینگ (فایلهای WAL) و استریمینگ رپلیکیشن. تنظیمات synchronous و asynchronous پیکربندی شده و فرآیند پروموت کردن استندبای به پرایمری به صورت دستی تمرین میگردد. درک صحیح این مفاهیم، پایهگذار طراحی کلاسترهای مقاوم در بخش بعدی خواهد بود.
primary_conninfo، primary_slot_namesynchronous_standby_names و تأثیر بر commitpg_stat_replicationpg_ctl promote و trigger fileرپلیکیشن به تنهایی کافی نیست؛ چه کسی در زمان خرابی پرایمری، استندبای را پروموت میکند؟ Patroni با بهرهگیری از Distributed Configuration Store (etcd، Consul، Zookeeper) این کار را به صورت خودکار و در چند ثانیه انجام میدهد. در این کارگاه عملی، یک کلاستر سهگرهای با Patroni راهاندازی شده و failover خودکار آزمایش میشود. سپس Pgpool-II به مجموعه اضافه میشود تا علاوه بر connection pooling، بار کوئریهای خواندنی را بین استندبایها توزیع کند. پس از این فصل، شرکتکننده قادر به طراحی و نگهداری کلاسترهایی با دسترسپذیری ۹۹٫۹۹٪ خواهد بود.
patroni.yml و پارامترهای bootstrapهر اتصال به PostgreSQL یک پروسس در سیستم عامل ایجاد میکند. در بارهای تراکنشی بالا، این مدل به سرعت به مشکل میخورد. pgBouncer با Transaction Pooling و Session Pooling این معضل را حل میکند. همچنین اگر نیاز به ثبت دقیق وقایع و حسابرسی دارید، pgAudit ابزاری است که با تنظیمات منعطف خود، تمامی دستورات حساس را ضبط میکند. در این فصل هر دو ابزار پیکربندی شده و در سناریوهای واقعی به کار گرفته میشوند.
pgbouncer.ini: database, user, pool size, reserve poolpgaudit.log، pgaudit.roleیک DBA کاربلد هر روز صبح پیش از هر کاری، سری به ویوهای سیستمی میزند. pg_stat*، pg_statio* و pg_stats پنجرههایی به درون موتور PostgreSQL هستند. در این فصل یاد گرفته میشود چطور کوئریهای طولانی، lockهای مزاحم، bloat جداول و ایندکسها و میزان IO را از همین ویوها استخراج کنیم. با این دانش، شرکتکننده از حالت واکنشی خارج شده و به یک مدیر پیشگیرانه (Proactive) تبدیل میشود.
pg_stat_activity: نشستهای فعال، کوئریهای در حال اجرا، waitingpg_stat_database: تراکنشها، deadlock، hit ratiopg_stat_all_tables: seq scan, idx scan, n_dead_tup, last_vacuumpg_stat_all_indexes: اسکن ایندکس، خواندن و واکشیpg_statio_*: hit rate، خواندن از دیسکpg_locks: شناسایی قفلهای مزاحم و blocked processespg_stats: histogram bounds, most common values, correlationشما نمیتوانید ۲۴ ساعته پای مانیتور بنشینید. یک داشبورد جامع مانیتورینگ، وضعیت سلامت کلاستر را در هر لحظه نمایش میدهد و پیش از آنکه کاربران متوجه کاهش عملکرد شوند، هشدار میفرستد. در این فصل، Prometheus و PostgreSQL exporter نصب و پیکربندی میشود، متریکهای کلیدی (تعداد تراکنشها، تأخیر رپلیکیشن، cache hit ratio، اندازه دیتابیس و …) جمعآوری و در Grafana مصورسازی میگردد. همچنین آلارمهای هوشمند برای بحرانهای احتمالی طراحی میشود.
postgres_exporterPostgreSQL امروز در مرکز تحول زیرساخت داده قرار دارد. پذیرندگان اولیه این فناوری، اکنون به مزیت رقابتی چشمگیری دست یافتهاند. این دوره فرصتی است تا شما نیز به جمع متخصصانی بپیوندید که توانایی طراحی، پیادهسازی و نگهداری کلاسترهای PostgreSQL در مقیاس سازمانی را دارند.