[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fkroW4bQg2tKLoYJ6BljGyYIt0r8itlLCl_241cifr-M":3},{"data":4,"related":88},{"id":5,"title":6,"slug":7,"excerpt":8,"cover":9,"category":11,"author":14,"track":20,"level":23,"reading_minutes":26,"is_featured":27,"published_at":28,"updated_at":28,"body":29,"toc":30,"tags":59,"faqs":75,"related_services":85,"comments_enabled":86,"meta_title":19,"meta_description":87,"canonical_url":19,"noindex":27,"is_live":86},2,"پرشدن دیسک PostgreSQL با WAL اسلات replication غیرفعال","postgresql-replication-slot-wal-disk-full","یک replication slot غیرفعال می‌تواند pg_wal را تا پر شدن کامل دیسک نگه دارد و دیتابیس را عملاً از کار بیندازد. در این مقاله ریشه‌یابی، رفع و پیشگیری از آن را گام‌به‌گام بررسی می‌کنیم.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002Ffc88585f-2f8a-4ddd-8903-43b0b8b4aacc.png",{"name":12,"slug":13},"مانیتورینگ و پایداری","monitoring",{"name":15,"slug":16,"role":17,"bio":18,"linkedin_url":19,"avatar_url":19},"تحریریه کلودیکپ","cloudicap-editorial","تیم محتوای کلودیکپ","تیم فنی و محتوای کلودیکپ؛ مهندسانی که هر روز با DevOps، Kubernetes و زیرساخت ابری کار می‌کنند و تجربه‌هایشان را اینجا می‌نویسند.",null,{"value":21,"label":22},"engineers","مهندسان",{"value":24,"label":25},"intermediate","متوسط",6,false,"2026-10-06T17:39:51+00:00","\u003Ch2 id=\"شرح-مسئله-دیسک-پر-می‌شود-ولی-داده‌ها-بزرگ-نشده‌اند\">شرح مسئله: دیسک پر می‌شود، ولی داده‌ها بزرگ نشده‌اند\u003C\u002Fh2>\n\u003Cp>داستان معمولاً این‌طور شروع می‌شود: یک شب هشدار می‌آید که فضای دیسک سرور دیتابیس از ۹۵٪ گذشته، یا صبح که به سرور سر می‌زنید اپلیکیشن خطا می‌دهد و در لاگ PostgreSQL این خطوط را می‌بینید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">FATAL:  could not write to file \"pg_wal\u002Fxlogtemp.28471\": No space left on device\nPANIC:  could not write to file \"pg_wal\u002Fxlogtemp.28471\": No space left on device\nLOG:  server process (PID 28471) was terminated by signal 6: Aborted\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>یا از سمت کلاینت:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">ERROR:  could not extend file \"base\u002F16384\u002F16927\": No space left on device\nHINT:  Check free disk space.\nERROR:  could not write to WAL: No space left on device\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>نشانه‌های همراه این وضعیت:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>دیتابیس عملاً read-only می‌شود؛ هر \u003Ccode>INSERT\u003C\u002Fcode>، \u003Ccode>UPDATE\u003C\u002Fcode> یا \u003Ccode>DELETE\u003C\u002Fcode> شکست می‌خورد و اپلیکیشن خطای ۵۰۰ می‌دهد.\u003C\u002Fli>\n\u003Cli>در لاگ، هشدار checkpoint هم تکرار می‌شود: \u003Ccode>checkpoints are occurring too frequently (12 seconds apart)\u003C\u002Fcode>.\u003C\u002Fli>\n\u003Cli>خروجی \u003Ccode>df -h\u003C\u002Fcode> نشان می‌دهد پارتیشن PGDATA روی ۱۰۰٪ است، اما حجم دیتای واقعی (\u003Ccode>base\u002F\u003C\u002Fcode>) رشد محسوسی نداشته.\u003C\u002Fli>\n\u003Cli>در \u003Ccode>$PGDATA\u002Fpg_wal\u003C\u002Fcode> هزاران فایل ۱۶ مگابایتی انبار شده است.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>در این لحظه فقط یک پرسش مهم وجود دارد: چه چیزی مانع بازیافت WAL شده است؟\u003C\u002Fp>\n\n\u003Ch2 id=\"علت-ریشه‌ای-اسلاتی-که-wal-را-قفل-می‌کند\">علت ریشه‌ای: اسلاتی که WAL را قفل می‌کند\u003C\u002Fh2>\n\u003Cp>PostgreSQL برای اینکه یک replica فیزیکی یا یک مصرف‌کننده منطقی (Debezium، pglogical، logical replication) بعد از قطعی بتواند از همان نقطه ادامه دهد، از replication slot استفاده می‌کند. برخلاف \u003Ccode>wal_keep_size\u003C\u002Fcode> که فقط یک «توصیه» است، اسلات یک \u003Cstrong>تضمین\u003C\u002Fstrong> است: سگمنت‌های WAL از نقطه‌ی \u003Ccode>restart_lsn\u003C\u002Fcode> آن اسلات به بعد، تا وقتی مصرف‌کننده آن‌ها را تأیید نکند، بازیافت نمی‌شوند.\u003C\u002Fp>\n\u003Cp>اگر مصرف‌کننده از کار بیفتد — یک standby خاموش، یک connector که کسی آن را حذف کرده اما اسلاتش یادش مانده — مقدار \u003Ccode>restart_lsn\u003C\u002Fcode> یخ می‌زند. از آن لحظه، هر checkpoint فقط WAL جدید تولید می‌کند و هیچ فایلی پاک نمی‌شود. نرخ تولید WAL در یک سیستم پرترافیک می‌تواند چند گیگابایت در ساعت باشد؛ یعنی چند ساعت تا پر شدن دیسک فاصله داریم.\u003C\u002Fp>\n\u003Cp>سه عامل دیگر که دقیقاً همین نشانه را تولید می‌کنند:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>شکست archive_command:\u003C\u002Fstrong> وقتی \u003Ccode>archive_mode = on\u003C\u002Fcode> است و آرشیو به مقصد (S3، NFS، ...) ناموفق بماند، سگمنت‌های WAL تا موفقیت آرشیو پاک نمی‌شوند و \u003Ccode>pg_wal\u002Farchive_status\u003C\u002Fcode> پر از فایل‌های \u003Ccode>.ready\u003C\u002Fcode> می‌شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>تراکنش باز و طولانی:\u003C\u002Fstrong> یک تراکنش باز — حتی فقط \u003Ccode>SELECT\u003C\u002Fcode> — مانع استفاده مجدد از فضای قدیمی می‌شود و فشار روی WAL را بالا می‌برد.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>wal_keep_size بزرگ:\u003C\u002Fstrong> اگر این پارامتر بی‌دلیل روی مقدار بالایی تنظیم شده باشد، WAL بیشتر از نیاز نگه داشته می‌شود. (البته به‌تنهایی به‌ندرت دیسک را پر می‌کند.)\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\n\n\u003Ch3 id=\"گام-۱-تأیید-اینکه-مقصر-pg-wal-است\">گام ۱: تأیید اینکه مقصر pg_wal است\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">df -h \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\nsudo -u postgres du -sh \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\u002Fpg_wal\nsudo -u postgres ls -1 \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\u002Fpg_wal | wc -l\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>و از داخل psql (کاربر \u003Ccode>postgres\u003C\u002Fcode> یا هر نقشی که \u003Ccode>pg_monitor\u003C\u002Fcode> دارد):\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT pg_size_pretty(sum(size)) AS wal_size,\n       count(*)                     AS wal_segments\nFROM pg_ls_waldir();\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>در حالت عادی، تعداد سگمنت‌ها حول \u003Ccode>max_wal_size\u003C\u002Fcode> (پیش‌فرض ۱ گیگابایت، یعنی حدود ۶۴ سگمنت) می‌چرخد. اگر عدد چند صد یا چند هزار است، مقصر مشخص است.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۲-پیدا-کردن-اسلات-مقصر\">گام ۲: پیدا کردن اسلات مقصر\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT slot_name,\n       slot_type,\n       database,\n       active,\n       restart_lsn,\n       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal\nFROM pg_replication_slots\nORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC NULLS LAST;\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>ترکیب \u003Ccode>active = false\u003C\u002Fcode> با \u003Ccode>retained_wal\u003C\u002Fcode> چند گیگابایتی، همان چیزی است که دنبالش هستید. روی PostgreSQL 13 و بالاتر ستون \u003Ccode>wal_status\u003C\u002Fcode> را هم اضافه کنید؛ مقادیر \u003Ccode>extended\u003C\u002Fcode> و \u003Ccode>unreserved\u003C\u002Fcode> یعنی اسلات از حد معمول فراتر رفته و وضعیت بحرانی است.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۳-بررسی-آرشیو-اگر-فعال-است\">گام ۳: بررسی آرشیو (اگر فعال است)\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT archived_count,\n       failed_count,\n       last_failed_wal,\n       last_failed_time\nFROM pg_stat_archiver;\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر \u003Ccode>failed_count\u003C\u002Fcode> بالا و \u003Ccode>last_failed_time\u003C\u002Fcode> نزدیک به الان است، ریشه‌ی پر شدن دیسک آرشیو است نه اسلات‌ها؛ در آن صورت مشکل مقصد آرشیو را حل کنید و آن‌گاه رهاسازی WAL خودبه‌خود انجام می‌شود.\u003C\u002Fp>\n\n\u003Ch3 id=\"گام-۴-تصمیم‌گیری-احیا-یا-حذف-اسلات\">گام ۴: تصمیم‌گیری — احیا یا حذف اسلات\u003C\u002Fh3>\n\u003Cp>اینجا نقطه‌ای است که باید آگاهانه انتخاب کنید، نه واکنشی:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>مصرف‌کننده برمی‌گردد:\u003C\u002Fstrong> اگر replica یا connector فقط قطع شده و می‌توانید در چند دقیقه آن را برگردانید، اسلات را دست نزنید. سرویس مصرف‌کننده را بالا بیاورید و صبر کنید \u003Ccode>restart_lsn\u003C\u002Fcode> جلو برود؛ WAL خودش آزاد می‌شود.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>مصرف‌کننده مرده است:\u003C\u002Fstrong> اگر آن replica یا connector دیگر وجود ندارد، اسلات را حذف کنید. این عمل برگشت‌پذیر نیست و مصرف‌کننده بعدی باید کامل resync کند.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- فقط وقتی مطمئن هستید که مصرف‌کننده این اسلات دیگر برنمی‌گردد\nSELECT pg_drop_replication_slot('debezium_slot');\n\n-- آزادسازی فوری فضای WAL\nCHECKPOINT;\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>اگر اسلات را فعال است، حذف با خطای \u003Ccode>replication slot \"x\" is active for PID 1234\u003C\u002Fcode> شکست می‌خورد؛ ابتدا سرویس مصرف‌کننده را متوقف کنید.\u003C\u002Fp>\n\u003Cp>اگر باید اسلات را نگه دارید ولی دیسک در حال پر شدن است، روی PostgreSQL 13+ می‌توانید سقف نگه‌داری WAL را برای اسلات‌ها محدود کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">ALTER SYSTEM SET max_slot_wal_keep_size = '5GB';\nSELECT pg_reload_conf();\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cblockquote>هشدار: با این تنظیم، اگر WAL نگه‌داشته‌شده از سقف بگذرد، اسلات در checkpoint بعدی invalidate می‌شود و مصرف‌کننده‌اش باید کامل resync کند. این یعنی ترجیح «دیسک زنده» بر «اسلات سالم»؛ یک تصمیم مهندسی است، نه یک تنظیم بی‌خطر. مقدار پیش‌فرض \u003Ccode>-1\u003C\u002Fcode> یعنی بدون محدودیت.\u003C\u002Fblockquote>\n\u003Cp>در وضعیتی که دیسک صفر شده و هیچ فضایی برای نفس کشیدن نیست، می‌توانید \u003Ccode>pg_wal\u003C\u002Fcode> را موقتاً به دیسکی دیگر منتقل کنید:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">systemctl stop postgresql\nmv \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\u002Fpg_wal \u002Fmnt\u002Ffast-disk\u002Fpg_wal\nln -s \u002Fmnt\u002Ffast-disk\u002Fpg_wal \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\u002Fpg_wal\nchown -R postgres:postgres \u002Fmnt\u002Ffast-disk\u002Fpg_wal\nsystemctl start postgresql\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>این کار فقط خرید زمان است، نه راه‌حل؛ بعد از آن باید پرونده‌ی اسلات را ببندید و مونیتورینگ \u003Ccode>pg_wal\u003C\u002Fcode> را جداگانه داشته باشید.\u003C\u002Fp>\n\n\u003Ch2 id=\"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است\">چطور مطمئن شویم مشکل واقعاً حل شده است\u003C\u002Fh2>\n\u003Col>\n\u003Cli>فضا آزاد شده است:\n\u003Cpre>\u003Ccode class=\"language-bash\">df -h \u002Fvar\u002Flib\u002Fpostgresql\u002F16\u002Fmain\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C\u002Fli>\n\u003Cli>نوشتن روی دیسک واقعاً کار می‌کند. با کاربر \u003Ccode>postgres\u003C\u002Fcode> یک سگمنت WAL جدید بسازید:\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT pg_switch_wal();\u003C\u002Fcode>\u003C\u002Fpre>\nاگر این دستور بدون خطای \u003Ccode>No space left on device\u003C\u002Fcode> برگردد، دیتابیس می‌تواند سگمنت جدید بنویسد.\n\u003C\u002Fli>\n\u003Cli>حجم WAL به محدوده‌ی نرمال برگشته است:\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT pg_size_pretty(sum(size)) AS wal_size FROM pg_ls_waldir();\u003C\u002Fcode>\u003C\u002Fpre>\n\u003C\u002Fli>\n\u003Cli>هیچ اسلاتی با WAL غیرمنتظره باقی نمانده است:\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT slot_name,\n       active,\n       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal\nFROM pg_replication_slots;\u003C\u002Fcode>\u003C\u002Fpre>\nروی اسلات‌های فعال باید \u003Ccode>active = true\u003C\u002Fcode> باشد و \u003Ccode>retained_wal\u003C\u002Fcode> کوچک و در حال نوسان.\n\u003C\u002Fli>\n\u003Cli>دیگر در لاگ \u003Ccode>checkpoints are occurring too frequently\u003C\u002Fcode> تکرار نمی‌شود و \u003Ccode>failed_count\u003C\u002Fcode> در \u003Ccode>pg_stat_archiver\u003C\u002Fcode> ثابت مانده است.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>WAL نگه‌داشته‌شده را پایش کنید، نه فقط فضای دیسک.\u003C\u002Fstrong> یک چک سبک هر ۵ دقیقه کافی است:\n\u003Cpre>\u003Ccode class=\"language-sql\">SELECT slot_name,\n       active,\n       pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS retained_bytes\nFROM pg_replication_slots\nWHERE pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) > 10737418240;\u003C\u002Fcode>\u003C\u002Fpre>\nهر ردیف این خروجی یعنی یک اسلات بیش از ۱۰ گیگابایت WAL قفل کرده است. خروجی این کوئری را به یک متریک یا هشدار تبدیل کنید.\n\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هشدار روی اسلات‌های غیرفعال:\u003C\u002Fstrong> \u003Ccode>SELECT count(*) FROM pg_replication_slots WHERE NOT active;\u003C\u002Fcode> اگر ناگهان بیشتر از حالت پایه شد، یعنی مصرف‌کننده‌ای از دست رفته است.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>هشدار روی آرشیو:\u003C\u002Fstrong> هرگونه رشد \u003Ccode>failed_count\u003C\u002Fcode> در \u003Ccode>pg_stat_archiver\u003C\u002Fcode> باید alert بزند، همراه با مونیتورینگ مقصد آرشیو.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>max_slot_wal_keep_size\u003C\u002Fcode> را از پیش‌فرض \u003Ccode>-1\u003C\u002Fcode> خارج کنید\u003C\u002Fstrong> (PostgreSQL 13+) و روی مقداری بگذارید که با ظرفیت دیسک شما سازگار است؛ این تنها تور محافظ در برابر اسلات یتیم است.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>مالکیت اسلات‌ها را مستند کنید.\u003C\u002Fstrong> هر اسلات باید در runbook یا IaC به یک سرویس مشخص گره خورده باشد؛ اسلات بدون مالک را همان روز حذف کنید.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>\u003Ccode>wal_keep_size\u003C\u002Fcode> را کوچک نگه دارید\u003C\u002Fstrong> و به‌جای آن به اسلات تکیه کنید؛ اسلات دقیق‌تر و قابل‌پایش‌تر است.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>تست دوره‌ای بازیابی مصرف‌کننده:\u003C\u002Fstrong> حداقل یک‌بار در فصل، connector یا standby را عمداً قطع و وصل کنید و ببینید با چه سرعتی به \u003Ccode>restart_lsn\u003C\u002Fcode> فعلی می‌رسد. این عدد تعیین می‌کند چند ساعت فرصت دارید.\u003C\u002Fli>\n\u003C\u002Ful>",[31,34,37,40,44,47,50,53,56],{"id":32,"text":33,"level":5},"شرح-مسئله-دیسک-پر-می‌شود-ولی-داده‌ها-بزرگ-نشده‌اند","شرح مسئله: دیسک پر می‌شود، ولی داده‌ها بزرگ نشده‌اند",{"id":35,"text":36,"level":5},"علت-ریشه‌ای-اسلاتی-که-wal-را-قفل-می‌کند","علت ریشه‌ای: اسلاتی که WAL را قفل می‌کند",{"id":38,"text":39,"level":5},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":41,"text":42,"level":43},"گام-۱-تأیید-اینکه-مقصر-pg-wal-است","گام ۱: تأیید اینکه مقصر pg_wal است",3,{"id":45,"text":46,"level":43},"گام-۲-پیدا-کردن-اسلات-مقصر","گام ۲: پیدا کردن اسلات مقصر",{"id":48,"text":49,"level":43},"گام-۳-بررسی-آرشیو-اگر-فعال-است","گام ۳: بررسی آرشیو (اگر فعال است)",{"id":51,"text":52,"level":43},"گام-۴-تصمیم‌گیری-احیا-یا-حذف-اسلات","گام ۴: تصمیم‌گیری — احیا یا حذف اسلات",{"id":54,"text":55,"level":5},"چطور-مطمئن-شویم-مشکل-واقعا-حل-شده-است","چطور مطمئن شویم مشکل واقعاً حل شده است",{"id":57,"text":58,"level":5},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[60,63,66,69,72],{"name":61,"slug":62},"PostgreSQL","postgresql",{"name":64,"slug":65},"WAL","wal",{"name":67,"slug":68},"Replication","replication",{"name":70,"slug":71},"پایداری","paydary",{"name":73,"slug":74},"مانیتورینگ","manytoryng",[76,79,82],{"question":77,"answer":78},"آیا حذف replication slot باعث از دست رفتن داده روی دیتابیس اصلی می‌شود؟","خیر. حذف اسلات هیچ داده‌ای را روی primary پاک نمی‌کند و فقط رابطه‌ی نگه‌داری WAL را قطع می‌کند. تنها پیامدش این است که مصرف‌کننده‌ای که به آن اسلات وابسته بود، دیگر نمی‌تواند از نقطه‌ی قبلی ادامه دهد و باید یک resync کامل انجام دهد.",{"question":80,"answer":81},"چرا بعد از pg_drop_replication_slot فضای دیسک فوراً آزاد نشد؟","بازیافت فایل‌های WAL در PostgreSQL هنگام checkpoint انجام می‌شود، نه بلافاصله بعد از حذف اسلات. بنابراین بعد از drop کردن اسلات (یا حل مشکل archive_command) یک CHECKPOINT اجرا کنید تا سگمنت‌های آزادشده حذف شوند؛ در غیر این صورت تا checkpoint بعدی ممکن است چند دقیقه منتظر بمانید.",{"question":83,"answer":84},"آیا می‌توانم فایل‌های WAL قدیمی را برای آزاد کردن فضا دستی پاک کنم؟","هرگز. \u003Ccode>pg_wal\u003C\u002Fcode> یک دایرکتوری مدیریت‌شده است و حذف دستی فایل‌ها باعث خطای Panic، خرابی کنترل‌فایل و در مواردی خرابی کل کلاستر می‌شود. مسیر درست این است که علت نگه‌داری WAL (اسلات، آرشیو یا تراکنش باز) را برطرف کنید و اجازه دهید checkpoint خودش فایل‌ها را بازیافت کند.",[],true,"چرا pg_wal دیسک PostgreSQL را پر می‌کند؟ ریشه‌یابی replication slot غیرفعال، دستورهای تشخیص، حذف ایمن اسلات و روش‌های پیشگیری.",[89],{"id":90,"title":91,"slug":92,"excerpt":93,"cover":94,"category":96,"author":97,"track":98,"level":99,"reading_minutes":100,"is_featured":27,"published_at":101,"updated_at":101},1,"«idle in transaction» در PostgreSQL: قاتل خاموش autovacuum","postgres-idle-in-transaction-autovacuum-bloat","نشست‌های idle in transaction تراکنش را باز نگه می‌دارند، جلوی autovacuum را می‌گیرند و جدول‌ها را باد می‌کنند تا جایی که دیسک پر و اتصال‌ها تمام می‌شود. این مقاله تشخیص و درمان کامل آن است.",{"url":95,"alt":91},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F0d697b95-c5d7-4b87-92f3-ae560e3d792e.png",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":24,"label":25},8,"2026-10-06T17:33:36+00:00"]