تکالیف نگهداری Apache Cassandra

این بخش وظایف نگهداری دوره‌ای برای Cassandra را شرح می‌دهد.

نگهداری ضدآنتروپی

گره‌های حلقه Apache Cassandra برای اطمینان از یکپارچگی در همه گره‌ها نیاز به نگهداری دوره‌ای دارند. برای انجام این نگهداری، از فرمان زیر استفاده کنید:

apigee-service apigee-cassandra apigee_repair -pr

‫Apigee هنگام اجرای این فرمان موارد زیر را توصیه می‌کند:

  • روی هر گره Cassandra (در همه مناطق یا مراکز داده) اجرا شود.

  • در هر زمان روی یک گره اجرا می‌شود تا از یکپارچگی در همه گره‌های حلقه اطمینان حاصل شود. اجرای هم‌زمان کارهای تعمیر روی چندین گره می‌تواند سلامت Cassandra را مختل کند.

    برای بررسی اینکه کار تعمیر در یک گره باموفقیت تکمیل شده است یا نه، در فایل system.log گره به‌دنبال ورودی با شناسه UUID آخرین جلسه تعمیر و عبارت «جلسه باموفقیت تکمیل شد» بگردید. در اینجا نمونه‌ای از ورودی گزارش آورده شده است:

    INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully"
Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
  • در دوره‌هایی که بار کاری نسبتاً پایین است اجرا کنید (این ابزار بار قابل‌توجهی بر سیستم تحمیل می‌کند).
  • حداقل هر هفت روز یک‌بار اجرا شود تا مشکلات مربوط به «حذف‌های فراموش‌شده» Cassandra برطرف شود.
  • در روزهای مختلف روی گره‌های مختلف اجرا کنید، یا آن را زمان‌بندی کنید تا بین اجرای آن روی هر گره چندین ساعت فاصله باشد.
  • از گزینه -pr (محدوده تقسیم‌کننده) برای مشخص کردن محدوده تقسیم‌کننده اصلی فقط گره استفاده کنید.

اگر اصالت‌سنجی JMX را برای Cassandra فعال کرده‌اید، باید نام کاربری و گذرواژه را هنگام فراخوانی nodetool اضافه کنید. برای مثال:

apigee-service apigee-cassandra apigee_repair -u username -pw password -pr

همچنین می‌توانید فرمان زیر را اجرا کنید تا گزینه‌های پشتیبانی‌شده apigee_repair: را بررسی کنید

apigee-service apigee-cassandra apigee_repair -h

توجه: apigee_repair یک پوشش برای تعمیر nodetool در Cassandra است، که قبل‌از انجام تعمیر Cassandra، بررسی‌های بیشتری انجام می‌دهد.

برای اطلاعات بیشتر، منابع زیر را ببینید:

نگهداری فایل گزارش

گزارش‌های Cassandra در دایرکتوری /opt/apigee/var/log/apigee-cassandra در هر گره ذخیره می‌شود. به‌طور پیش‌فرض، حداکثر ۵۰ فایل گزارش، که هرکدام حداکثر ۲۰ مگابایت حجم دارند، می‌توانند ایجاد شوند؛ وقتی این حد مجاز پر شد، گزارش‌های قدیمی‌تر با ایجاد گزارش‌های جدیدتر حذف می‌شوند.

اگر متوجه شدید که فایل‌های گزارش Cassandra فضای بیش‌ازحدی را اشغال می‌کنند، می‌توانید با ویرایش تنظیمات log4j، مقدار فضای اختصاص‌داده‌شده برای فایل‌های گزارش را تغییر دهید.

  1. برای تنظیم کردن ویژگی‌های زیر، /opt/apigee/customer/application/cassandra.properties را ویرایش کنید. اگر آن فایل وجود ندارد، آن را ایجاد کنید: 
    conf_logback_maxfilesize=20MB
# max file size
conf_logback_maxbackupindex=50 # max open files
  2. بااستفاده از فرمان زیر، Cassandra را بازراه‌اندازی کنید: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

نگهداری فضای دیسک

باید به‌طور منظم از میزان استفاده از دیسک Cassandra نظارت کنید تا مطمئن شوید حداقل ۵۰ درصد از هر دیسک آزاد است. اگر استفاده از دیسک از ۵۰ درصد فراتر رفت، توصیه می‌کنیم فضای دیسک بیشتری اضافه کنید تا درصد استفاده کاهش یابد.

«کاساندرا» به‌طور خودکار عملیات زیر را برای کاهش استفاده از دیسک خود انجام می‌دهد:

  • حذف کد اصالت‌سنجی هنگام منقضی شدن کدها. بااین‌حال، بسته به پیکربندی‌تان، ممکن است چند هفته طول بکشد تا فضای دیسکی که نشانه‌ها استفاده می‌کردند آزاد شود. اگر حذف خودکار برای حفظ فضای دیسک کافی نیست، برای آشنایی با نحوه حذف دستی نشان‌ها برای بازیابی فضا، با پشتیبانی تماس بگیرید.

  • یادداشت درباره فشرده‌سازی داده‌ها: از Edge for Private Cloud 4.51.00، نصب‌های جدید Apigee Cassandra فضاهای کلیدی را با استراتژی فشرده‌سازی سطحی ایجاد خواهد کرد.

    نصب نسخه‌های قدیمی‌تر Edge for Private Cloud که به Private Cloud 4.51.00 ارتقا یافته‌اند همچنان از استراتژی فشرده‌سازی قبلی استفاده خواهند کرد. اگر استراتژی فشرده‌سازی موجود SizeTieredCompactionStrategy است، توصیه می‌کنیم آن را به LeveledCompactionStrategy تغییر دهید، که استفاده بهتری از دیسک ارائه می‌دهد.

توجه: وقتی Cassandra فشرده‌سازی داده‌ها را انجام می‌دهد، ممکن است مقدار قابل‌توجهی از چرخه‌های واحد پردازش مرکزی و حافظه را مصرف کند. اما پس‌از تکمیل فشرده‌سازی‌ها، استفاده از منابع باید به حالت عادی برگردد. می‌توانید فرمان 'Nodetool compactionstats' را روی هر گره اجرا کنید تا بررسی کنید که آیا فشرده‌سازی درحال اجرا است یا خیر. برونداد compactionstats به شما اطلاع می‌دهد که آیا فشرده‌سازی معلقی برای اجرا وجود دارد یا نه و زمان تخمینی تکمیل آن چقدر است.