[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fuywcEZlG651-w49ZgJO5JYIt4eQVeMPIGHAv3DE5z3E":3},{"data":4,"related":90},{"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":63,"faqs":75,"related_services":85,"comments_enabled":88,"meta_title":19,"meta_description":89,"canonical_url":19,"noindex":27,"is_live":88},16,"پر شدن فضای etcd؛ خطای mvcc: database space exceeded","etcd-mvcc-database-space-exceeded-fix","وقتی فایل backend در etcd از فضای تعیین‌شده عبور می‌کند، کل کلاستر Kubernetes به حالت فقط‌خواندنی می‌رود. در این مقاله علت fragmentation را بررسی می‌کنیم و با defrag، disarm و تنظیم quota کلاستر را برمی‌گردانیم.",{"url":10,"alt":6},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F8e23ae4a-9378-4437-993a-3c839a851a9a.webp",{"name":12,"slug":13},"Kubernetes و کانتینر","kubernetes",{"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},"advanced","پیشرفته",7,false,"2026-10-18T10:56:24+00:00","\u003Cp>اگر یک روز صبح \u003Ccode>kubectl apply\u003C\u002Fcode> با خطای عجیبی برگردد، هیچ پاد جدیدی ساخته نشود، اما \u003Ccode>kubectl get\u003C\u002Fcode> همچنان بی‌مشکل کار کند، احتمال زیادی وجود دارد که با کلاسیک‌ترین حالت خرابی کنترل‌پلین روبه‌رو شده باشید: پر شدن فضای ذخیره‌سازی etcd. این مقاله دقیقاً همان سناریو را بررسی می‌کند.\u003C\u002Fp>\u003Ch2 id=\"شرح-مسئله\">شرح مسئله\u003C\u002Fh2>\u003Cp>نشانه اصلی، پیامی است که هم از سمت کلاینت و هم در لاگ kube-apiserver دیده می‌شود:\u003C\u002Fp>\u003Cblockquote>\u003Cp>Error from server: etcdserver: mvcc: database space exceeded\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>در لاگ kube-apiserver هم خطوطی شبیه این تکرار می‌شود:\u003C\u002Fp>\u003Cblockquote>\u003Cp>{\"level\":\"warn\",\"msg\":\"etcdserver: mvcc: database space exceeded\",\"logger\":\"etcd-client\"}\u003Cbr>{\"level\":\"error\",\"msg\":\"Updating endpoint failed\",\"logger\":\"apiserver\"}\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>رفتاری که در عمل می‌بینید:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>عملیات خواندن (\u003Ccode>kubectl get\u003C\u002Fcode>، \u003Ccode>kubectl describe\u003C\u002Fcode>) سالم است؛ حتی پادهای در حال اجرا به کار خود ادامه می‌دهند.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>هر عملیات نوشتن شکست می‌خورد: \u003Ccode>apply\u003C\u002Fcode>، \u003Ccode>create\u003C\u002Fcode>، \u003Ccode>scale\u003C\u002Fcode>، ساخت Secret، به‌روزرسانی Deployment.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>kube-controller-manager نمی‌تواند leader election را تمدید کند و مدام restart می‌شود؛ در نتیجه garbage collection و HPA هم از کار می‌افتند.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>رویدادهای جدید ثبت نمی‌شوند؛ \u003Ccode>kubectl get events\u003C\u002Fcode> عملاً منجمد می‌شود.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>خروجی \u003Ccode>etcdctl endpoint status\u003C\u002Fcode> نشان می‌دهد حجم دیتابیس به سقف نزدیک شده است.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>نکته مهم این است که این وضعیت «خرابی» نیست؛ etcd عمداً برای حفظ یکپارچگی داده، نوشتن را رد می‌کند. کلاستر زنده است، ولی عملاً قفل شده.\u003C\u002Fp>\u003Ch2 id=\"علت-ریشه‌ای\">علت ریشه‌ای\u003C\u002Fh2>\u003Cp>etcd از مدل \u003Cstrong>MVCC\u003C\u002Fstrong> استفاده می‌کند. هر نوشتن یک \u003Ccode>revision\u003C\u002Fcode> جدید می‌سازد و کلید قدیمی پاک نمی‌شود؛ فقط نسخه جدید اضافه می‌شود. کلیدهای حذف‌شده هم به‌صورت tombstone باقی می‌مانند. تا وقتی این نسخه‌های قدیمی \u003Cem>compact\u003C\u002Fem> نشوند، فضای منطقی آن‌ها آزاد نمی‌شود.\u003C\u002Fp>\u003Cp>مسئله دوم اما جایی است که بیشتر مهندسان را گمراه می‌کند: \u003Cstrong>compact کردن، فایل را کوچک نمی‌کند\u003C\u002Fstrong>. فایل backend یک فایل bbolt است و پس از compact شدن، صفحات آزاد داخل همان فایل می‌مانند. برای برگرداندن این فضا به فایل‌سیستم، باید \u003Cstrong>defrag\u003C\u002Fstrong> انجام شود. به همین دلیل معمولاً این الگو را می‌بینید: حجم فایل دیتابیس بالا می‌رود، اما حجم in-use پایین است و رشد نمی‌کند.\u003C\u002Fp>\u003Cp>وقتی حجم فایل backend از مقدار \u003Ccode>--quota-backend-bytes\u003C\u002Fcode> (پیش‌فرض ۲ گیبی‌بایت) عبور کند، etcd یک آلارم از نوع \u003Ccode>NOSPACE\u003C\u002Fcode> فعال می‌کند و تا زمانی که این آلارم برداشته نشود، همه نوشتن‌ها رد می‌شوند. همین است که کلاستر فقط‌خواندنی می‌شود.\u003C\u002Fp>\u003Cp>منابع رایج این رشد در کلاسترهای \u003Ca href=\"\u002Fservices\u002Fkubernetes\">Kubernetes\u003C\u002Fa>:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>رویدادها (Events) با نرخ بالا، به‌خصوص وقتی کسی چرخه‌ای از restart پادها دارد.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Jobs و CronJobs بدون \u003Ccode>ttlSecondsAfterFinished\u003C\u002Fcode> که تاریخچه انبوه تولید می‌کنند.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Secretهای بزرگ (مثل kubeconfig یا کلیدهای TLS حجیم) که مرتب به‌روزرسانی می‌شوند.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>churn در Endpoints و Leaseها در کلاسترهای پرترافیک.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>به‌روزرسانی‌های پرتکرار Helm\u002FGitOps روی Deploymentهای بزرگ با manifestهای چندصد کیلوبایتی.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>توجه داشته باشید که kube-apiserver به‌طور پیش‌فرض هر ۵ دقیقه compaction انجام می‌دهد (\u003Ccode>--etcd-compaction-interval\u003C\u002Fcode>)، پس در محیط Kubernetes معمولاً مشکل «کمپکت نشدن» نیست؛ مشکل \u003Cstrong>fragmentation\u003C\u002Fstrong> است.\u003C\u002Fp>\u003Ch2 id=\"راه‌حل-گام‌به‌گام\">راه‌حل گام‌به‌گام\u003C\u002Fh2>\u003Ch3 id=\"گام-۰-بکاپ-بگیرید\">گام ۰: بکاپ بگیرید\u003C\u002Fh3>\u003Cp>قبل از هر کاری، یک snapshot سالم بگیرید. بدون این گام سراغ defrag نروید.\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">export ETCDCTL_API=3\nexport ETCDCTL_CACERT=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fca.crt\nexport ETCDCTL_CERT=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fserver.crt\nexport ETCDCTL_KEY=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fserver.key\n\netcdctl --endpoints=https:\u002F\u002F127.0.0.1:2379 \\\n  snapshot save \u002Fvar\u002Fbackups\u002Fetcd-$(date +%F-%H%M).db\n\netcdctl snapshot status \u002Fvar\u002Fbackups\u002Fetcd-*.db --write-out=table\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch3 id=\"گام-۱-وضعیت-و-آلارم‌ها-را-تأیید-کنید\">گام ۱: وضعیت و آلارم‌ها را تأیید کنید\u003C\u002Fh3>\u003Cpre>\u003Ccode class=\"language-bash\">etcdctl --endpoints=https:\u002F\u002F10.0.0.11:2379,https:\u002F\u002F10.0.0.12:2379,https:\u002F\u002F10.0.0.13:2379 \\\n  endpoint status --write-out=table\n\netcdctl --endpoints=https:\u002F\u002F10.0.0.11:2379,https:\u002F\u002F10.0.0.12:2379,https:\u002F\u002F10.0.0.13:2379 \\\n  alarm list\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>خروجی جدول ستون‌های \u003Ccode>DB SIZE\u003C\u002Fcode>، \u003Ccode>IS LEADER\u003C\u002Fcode>، \u003Ccode>RAFT INDEX\u003C\u002Fcode> و \u003Ccode>ERRORS\u003C\u002Fcode> را نشان می‌دهد. اگر \u003Ccode>DB SIZE\u003C\u002Fcode> نزدیک فضای آن است و \u003Ccode>alarm list\u003C\u002Fcode> عضوی با آلارم \u003Ccode>NOSPACE\u003C\u002Fcode> برمی‌گرداند، تشخیص تأیید است. توجه کنید که \u003Ccode>DB SIZE\u003C\u002Fcode> باید در همه اعضا نزدیک به هم باشد؛ اختلاف فاحش یعنی یک عضو از کلاستر عقب مانده و مشکل جداگانه‌ای دارید.\u003C\u002Fp>\u003Ch3 id=\"گام-۲-defrag-اعضا-یکی‌یکی-و-از-followerها-شروع-کنید\">گام ۲: defrag اعضا، یکی‌یکی و از followerها شروع کنید\u003C\u002Fh3>\u003Cp>defrag یک عملیات \u003Cstrong>blocking\u003C\u002Fstrong> است؛ در طول اجرا آن عضو نمی‌تواند به خواندن و نوشتن پاسخ دهد. در کلاستر سه‌عضوی، تا وقتی quorum حفظ شود سرویس‌دهی ادامه دارد، اما ترتیب کار مهم است: اول followerها، آخر leader.\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">for ep in https:\u002F\u002F10.0.0.12:2379 https:\u002F\u002F10.0.0.13:2379 https:\u002F\u002F10.0.0.11:2379; do\n  echo \"### defrag $ep\"\n  etcdctl --endpoints=$ep defrag --command-timeout=600s\ndone\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>مقدار \u003Ccode>--command-timeout\u003C\u002Fcode> را بزرگ‌تر از زمان مورد انتظار defrag بگذارید؛ در دیتابیس‌های چند گیگی، defrag می‌تواند چند دقیقه طول بکشد و تایم‌اوت پیش‌فرض ۵ ثانیه‌ای etcdctl باعث می‌شود فکر کنید عملیات شکست خورده، در حالی که در سرور ادامه دارد.\u003C\u002Fp>\u003Cp>اگر etcd به‌صورت static pod در کلاستر kubeadm اجرا می‌شود، همین کار را داخل پاد انجام دهید:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">kubectl -n kube-system exec -it etcd-cp1 -- sh -c '\n  ETCDCTL_API=3 etcdctl \\\n    --endpoints=https:\u002F\u002F127.0.0.1:2379 \\\n    --cacert=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fca.crt \\\n    --cert=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fserver.crt \\\n    --key=\u002Fetc\u002Fkubernetes\u002Fpki\u002Fetcd\u002Fserver.key \\\n    defrag --command-timeout=600s'\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>در محیط external etcd، همین دستور را روی خود ماشین‌ها با آدرس‌های واقعی هر عضو اجرا کنید.\u003C\u002Fp>\u003Ch3 id=\"گام-۳-آلارم-را-بردارید\">گام ۳: آلارم را بردارید\u003C\u002Fh3>\u003Cp>تا زمانی که آلارم فعال است، حتی اگر فایل کوچک شده باشد، نوشتن‌ها رد می‌شوند. بعد از defrag موفق روی همه اعضا:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">etcdctl --endpoints=https:\u002F\u002F10.0.0.11:2379,https:\u002F\u002F10.0.0.12:2379,https:\u002F\u002F10.0.0.13:2379 \\\n  alarm disarm\n\netcdctl --endpoints=https:\u002F\u002F10.0.0.11:2379,https:\u002F\u002F10.0.0.12:2379,https:\u002F\u002F10.0.0.13:2379 \\\n  alarm list\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>خروجی \u003Ccode>alarm list\u003C\u002Fcode> باید خالی باشد (یا \u003Ccode>memberID:0 alarm:NONE\u003C\u002Fcode>). اگر بعد از disarm دوباره بلافاصله آلارم برگشت، یعنی حجم فایل هنوز بالای فضای آن است و defrag انجام نشده یا ناقص مانده.\u003C\u002Fp>\u003Cp>در مواردی که compaction غیرفعال بوده (مثلاً etcd مستقل خارج از Kubernetes)، قبل از defrag باید compact کنید:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">EP=https:\u002F\u002F127.0.0.1:2379\nREV=$(etcdctl --endpoints=$EP endpoint status -w json | jq -r '.[0].Status.header.revision')\netcdctl --endpoints=$EP compact \"$REV\"\u003C\u002Fcode>\u003C\u002Fpre>\u003Ch3 id=\"گام-۴-فضای-etcd-و-compaction-را-درست-تنظیم-کنید\">گام ۴: فضای etcd و compaction را درست تنظیم کنید\u003C\u002Fh3>\u003Cp>اگر بعد از پاک‌سازی، رشد دوباره سریع است، فضای آن را بالا ببرید. سقف توصیه‌شده ۸ گیبی‌بایت است؛ بیشتر از این، هم defrag را طولانی می‌کند و هم بازیابی snapshot را.\u003C\u002Fp>\u003Cp>در کلاستر kubeadm، مانیفست \u003Ccode>\u002Fetc\u002Fkubernetes\u002Fmanifests\u002Fetcd.yaml\u003C\u002Fcode> را ویرایش کنید و فلگ‌ها را به \u003Ccode>command\u003C\u002Fcode> اضافه کنید:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-yaml\">spec:\n  containers:\n  - name: etcd\n    command:\n    - etcd\n    - --quota-backend-bytes=4294967296\n    - --auto-compaction-mode=periodic\n    - --auto-compaction-retention=1h\n    # ... سایر فلگ‌های موجود را دست نزنید\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>برای محیط‌هایی که با kubeadm از فایل پیکربندی نصب شده‌اند، معادل آن در \u003Ccode>ClusterConfiguration\u003C\u002Fcode> این‌طور است:\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-yaml\">kind: ClusterConfiguration\netcd:\n  local:\n    extraArgs:\n      quota-backend-bytes: '4294967296'\n      auto-compaction-mode: periodic\n      auto-compaction-retention: '1h'\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>تغییر مانیفست static pod باعث restart خودکار etcd می‌شود؛ اعضا را یکی‌یکی تغییر دهید، نه همه با هم. مقدار \u003Ccode>auto-compaction-retention\u003C\u002Fcode> در نسخه‌های قدیمی‌تر پیش‌فرض صفر (غیرفعال) است، پس صریح تنظیمش کنید.\u003C\u002Fp>\u003Ch2 id=\"بررسی-اینکه-مشکل-واقعا-حل-شده-است\">بررسی اینکه مشکل واقعاً حل شده است\u003C\u002Fh2>\u003Cp>صرفاً دیدن پیام خالی در ترمینال کافی نیست. این چهار بررسی را انجام دهید:\u003C\u002Fp>\u003Col>\u003Cli>\u003Cp>\u003Cstrong>تست نوشتن واقعی:\u003C\u002Fstrong> \u003Ccode>kubectl create configmap etcd-write-test --from-literal=a=b -n default\u003C\u002Fcode> و بعد حذفش. اگر بدون خطا انجام شد، مسیر نوشتن باز است.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>حجم دیتابیس:\u003C\u002Fstrong> دوباره \u003Ccode>endpoint status --write-out=table\u003C\u002Fcode> بگیرید؛ \u003Ccode>DB SIZE\u003C\u002Fcode> باید به‌طور محسوس (معمولاً ۳۰ تا ۷۰ درصد) کاهش یافته باشد. اگر کاهش نداشت، defrag روی آن عضو اجرا نشده است.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>لاگ apiserver:\u003C\u002Fstrong> شمارش خطا باید صفر شود: \u003Ccode>kubectl -n kube-system logs kube-apiserver-cp1 | grep -c \"database space exceeded\"\u003C\u002Fcode>. اگر عدد بزرگ است، لاگ قدیمی است؛ از \u003Ccode>--since=10m\u003C\u002Fcode> استفاده کنید تا فقط بازه بعد از رفع مشکل دیده شود.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>سلامت کنترل‌پلین:\u003C\u002Fstrong> \u003Ccode>kubectl get --raw='\u002Freadyz?verbose'\u003C\u002Fcode> باید همه چک‌ها را \u003Ccode>ok\u003C\u002Fcode> نشان دهد و \u003Ccode>kubectl -n kube-system get lease kube-controller-manager -o yaml\u003C\u002Fcode> باید مرتب به‌روزرسانی شود.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Fol>\u003Cp>برای مقایسه، وضعیت مورد انتظار بعد از رفع مشکل:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Cth>\u003Cp>نشانه\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>قبل از رفع\u003C\u002Fp>\u003C\u002Fth>\u003Cth>\u003Cp>بعد از رفع\u003C\u002Fp>\u003C\u002Fth>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>alarm list\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>NOSPACE\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>خالی\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>DB SIZE\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>~ فضا\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>کاهش محسوس\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>kubectl apply\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>database space exceeded\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>موفق\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>leader election\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>restart مکرر\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>پایدار\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2 id=\"پیشگیری-و-بهترین-روش‌ها\">پیشگیری و بهترین روش‌ها\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>آلارم روی نسبت مصرف فضای آن بگذارید\u003C\u002Fstrong>، نه روی حجم مطلق. آستانه ۷۰ درصد نقطه خوبی است: \u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-bash\">(etcd_mvcc_db_total_size_in_bytes \u002F etcd_server_quota_backend_bytes) > 0.7\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp> در etcd 3.5 به بعد، متریک حجم دیتابیس با نام \u003Ccode>etcd_db_total_size_in_bytes\u003C\u002Fcode> هم منتشر می‌شود؛ در کلاستر خودتان چک کنید کدام نام فعال است.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>نسبت fragmentation را رصد کنید:\u003C\u002Fstrong> اگر حجم فایل چند برابر حجم in-use شد (نسبت بزرگ‌تر از ۳)، زمان defrag دوره‌ای رسیده است.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>churn را کم کنید:\u003C\u002Fstrong> برای همه Jobها \u003Ccode>ttlSecondsAfterFinished\u003C\u002Fcode> بگذارید، از ثبت رویدادهای پرحجم پرهیز کنید، و Secret\u002FConfigMapهای بزرگ را در جای لازم نگه ندارید.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>defrag را زمان‌بندی کنید:\u003C\u002Fstrong> در کلاسترهای پرترافیک، یک CronJob یا playbook ماهانه که اعضا را یکی‌یکی defrag می‌کند، از وقوع دوباره این حادثه جلوگیری می‌کند. هیچ‌وقت همه اعضا را همزمان defrag نکنید.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>روی دیسک و fsync سرمایه‌گذاری کنید:\u003C\u002Fstrong> etcd به تأخیر دیسک حساس است؛ NVMe با IOPS پایدار، هم defrag را سریع می‌کند هم احتمال از دست دادن leader را کاهش می‌دهد.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>سقف ۸ گیگابایت را جدی بگیرید:\u003C\u002Fstrong> بالا بردن quota راه‌حل موقت است، نه جایگزین کنترل churn.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>جمع‌بندی کوتاه: «database space exceeded» یعنی فایل backend از فضای آن گذشته و آلارم NOSPACE فعال است. مسیر درست، بکاپ → defrag عضو به عضو → disarm آلارم → تنظیم quota و compaction است؛ و مسیر اشتباه، فقط بالا بردن quota بدون کوچک کردن فایل.\u003C\u002Fp>",[31,35,38,41,45,48,51,54,57,60],{"id":32,"text":33,"level":34},"شرح-مسئله","شرح مسئله",2,{"id":36,"text":37,"level":34},"علت-ریشه‌ای","علت ریشه‌ای",{"id":39,"text":40,"level":34},"راه‌حل-گام‌به‌گام","راه‌حل گام‌به‌گام",{"id":42,"text":43,"level":44},"گام-۰-بکاپ-بگیرید","گام ۰: بکاپ بگیرید",3,{"id":46,"text":47,"level":44},"گام-۱-وضعیت-و-آلارم‌ها-را-تأیید-کنید","گام ۱: وضعیت و آلارم‌ها را تأیید کنید",{"id":49,"text":50,"level":44},"گام-۲-defrag-اعضا-یکی‌یکی-و-از-followerها-شروع-کنید","گام ۲: defrag اعضا، یکی‌یکی و از followerها شروع کنید",{"id":52,"text":53,"level":44},"گام-۳-آلارم-را-بردارید","گام ۳: آلارم را بردارید",{"id":55,"text":56,"level":44},"گام-۴-فضای-etcd-و-compaction-را-درست-تنظیم-کنید","گام ۴: فضای etcd و compaction را درست تنظیم کنید",{"id":58,"text":59,"level":34},"بررسی-اینکه-مشکل-واقعا-حل-شده-است","بررسی اینکه مشکل واقعاً حل شده است",{"id":61,"text":62,"level":34},"پیشگیری-و-بهترین-روش‌ها","پیشگیری و بهترین روش‌ها",[64,65,67,70,72],{"name":13,"slug":13},{"name":66,"slug":66},"etcd",{"name":68,"slug":69},"کنترل‌پلین","kntrlplyn",{"name":71,"slug":71},"defrag",{"name":73,"slug":74},"ذخیره‌سازی","thkhyrhsazy",[76,79,82],{"question":77,"answer":78},"تفاوت compact و defrag در etcd چیست؟","compact نسخه‌های قدیمی کلیدها را از نظر منطقی حذف می‌کند و فضای in-use را کم می‌کند، اما فایل backend کوچک نمی‌شود. defrag فایل را بازنویسی می‌کند و صفحات آزاد را به فایل‌سیستم برمی‌گرداند. برای عبور از فضای آن ، defrag الزامی است.",{"question":80,"answer":81},"آیا باید کلاستر را برای defrag از دسترس خارج کنم؟","در کلاستر سه‌عضوی لازم نیست، به شرطی که اعضا را یکی‌یکی و از followerها شروع کنید تا quorum حفظ شود. در کلاستر تک‌عضوی یا عضوهای دو‌تایی، قطعی کوتاه اجتناب‌ناپذیر است، چون defrag آن عضو را blocking می‌کند.",{"question":83,"answer":84},"چرا بعد از defrag هنوز خطا می‌گیرم؟","احتمالاً آلارم NOSPACE را disarm نکرده‌اید. تا وقتی آلارم فعال است، etcd همه نوشتن‌ها را رد می‌کند حتی اگر فایل کوچک شده باشد. اگر بعد از disarm هم بلافاصله آلارم برگشت، defrag روی همه اعضا کامل نشده یا حجم فایل هنوز بالای فضای آن است.",[13,86,87],"cloud-migration","performance-cost-optimization",true,"رفع خطای mvcc: database space exceeded در etcd؛ آموزش گام‌به‌گام defrag، compact کردن و alarm disarm برای بازگرداندن کلاستر Kubernetes از حالت فقط‌خواندنی.",[91,105,117],{"id":92,"title":93,"slug":94,"excerpt":95,"cover":96,"category":98,"author":99,"track":100,"level":101,"reading_minutes":26,"is_featured":27,"published_at":104,"updated_at":104},12,"خطای fsnotify watcher در Kubernetes؛ سقف inotify نود","kubernetes-fsnotify-watcher-inotify-limit","اگر پادهای Grafana، Prometheus یا هر اپلیکیشنی که از inotify استفاده می‌کند با خطای «failed to create fsnotify watcher: too many open files» کرش می‌کنند، مقصر سقف پیش‌فرض هسته لینوکس روی نود است.",{"url":97,"alt":93},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F4781a89b-ab2c-4250-9677-521b30f6f643.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":102,"label":103},"intermediate","متوسط","2026-10-13T09:37:29+00:00",{"id":106,"title":107,"slug":108,"excerpt":109,"cover":110,"category":112,"author":113,"track":114,"level":115,"reading_minutes":26,"is_featured":27,"published_at":116,"updated_at":116},11,"تأخیر ۵ ثانیه‌ای DNS در Kubernetes؛ پای ndots:5 در میان است","kubernetes-dns-ndots5-latency","هرچند وقت یک‌بار یک درخواست خروجی دقیقاً ۵ ثانیه طول می‌کشد و بعد موفق می‌شود؟ ریشه معمولاً گزینه ndots:5 در resolv.conf پادها و لیست search است. این مقاله علت، تشخیص و راه‌حل کامل را بررسی می‌کند.",{"url":111,"alt":107},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F79a6c679-300c-4c45-b692-9edb968f1d49.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":102,"label":103},"2026-10-12T09:53:03+00:00",{"id":118,"title":119,"slug":120,"excerpt":121,"cover":122,"category":124,"author":125,"track":126,"level":127,"reading_minutes":128,"is_featured":27,"published_at":129,"updated_at":129},9,"پاد Kubernetes در وضعیت Terminating گیر کرده؛ آزادسازی امن","kubernetes-pod-stuck-terminating-finalizer","پاد در حالت Terminating گیر کرده و با kubectl delete پاک نمی‌شود؟ این مقاله علت واقعی (finalizer باقی‌مانده، نود NotReady، ولوم گیرکرده) و راه‌حل گام‌به‌گام امن را نشان می‌دهد.",{"url":123,"alt":119},"https:\u002F\u002Fapi.cloudicap.com\u002Fmedia\u002Fposts\u002F8e6369a3-ad85-4e7e-8588-183bbd5a31f9.webp",{"name":12,"slug":13},{"name":15,"slug":16,"role":17,"avatar_url":19},{"value":21,"label":22},{"value":102,"label":103},6,"2026-10-10T09:34:08+00:00"]