این بخش وظایف نگهداری دوره ای را برای کاساندرا شرح می دهد.
نگهداری ضد آنتروپی
گره های حلقه آپاچی کاساندرا برای اطمینان از ثبات در همه گره ها نیاز به تعمیر و نگهداری دوره ای دارند. برای انجام این نگهداری از دستور زیر استفاده کنید:
apigee-service apigee-cassandra apigee_repair -pr
Apigee هنگام اجرای این دستور موارد زیر را توصیه می کند:
- روی هر گره کاساندرا (در تمام مناطق یا مراکز داده) اجرا شود.
برای اطمینان از سازگاری در تمام گره‌های حلقه، در یک نود اجرا کنید. اجرای کارهای تعمیر بر روی چندین گره به طور همزمان می تواند سلامت کاساندرا را مختل کند.
برای بررسی اینکه آیا یک کار تعمیر در یک گره با موفقیت انجام شده است، در فایل
system.logگره ها به دنبال ورودی با UUID آخرین جلسه تعمیر و عبارت "sesion temam شد با موفقیت" باشید. در اینجا یک نمونه ورودی گزارش آمده است: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
- در دوره‌هایی با حجم کار نسبتاً کم اجرا شود (ابزار بار قابل‌توجهی به سیستم تحمیل می‌کند).
- حداقل هر هفت روز یکبار اجرا کنید تا مشکلات مربوط به "حذف های فراموش شده" کاساندرا را از بین ببرید.
- بر روی گره های مختلف در روزهای مختلف اجرا کنید، یا آن را طوری برنامه ریزی کنید که بین اجرای آن در هر گره چندین ساعت فاصله باشد.
- از گزینه
-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/cassandra در هر گره ذخیره می‌شوند. به طور پیش فرض، حداکثر 50 فایل لاگ، هر کدام با حداکثر حجم 20 مگابایت، می تواند ایجاد شود. پس از رسیدن به این حد، گزارش‌های قدیمی‌تر با ایجاد گزارش‌های جدیدتر حذف می‌شوند.
اگر متوجه شدید که فایل‌های گزارش Cassandra فضای زیادی اشغال می‌کنند، می‌توانید با ویرایش تنظیمات log4j، مقدار فضای اختصاص داده شده برای فایل‌های گزارش را تغییر دهید.
- برای تنظیم ویژگی های زیر
/opt/apigee/customer/application/cassandra.propertiesرا ویرایش کنید. اگر آن فایل وجود ندارد، آن را ایجاد کنید:conf_logback_maxfilesize=20MB # max file size conf_logback_maxbackupindex=50 # max open files
- با استفاده از دستور زیر کاساندرا را مجددا راه اندازی کنید:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
نگهداری فضای دیسک
شما باید استفاده از دیسک کاساندرا را به طور منظم نظارت کنید تا مطمئن شوید که حداقل 50 درصد از هر دیسک رایگان است. اگر میزان استفاده از دیسک به بیش از 50 درصد رسید، توصیه می کنیم برای کاهش درصد استفاده، فضای دیسک بیشتری اضافه کنید.
Cassandra به طور خودکار عملیات زیر را برای کاهش استفاده از دیسک خود انجام می دهد:
- حذف رمز احراز هویت زمانی که توکن ها منقضی می شوند. با این حال، بسته به پیکربندی شما ممکن است چند هفته طول بکشد تا فضای دیسکی که توکن ها استفاده می کردند آزاد شود. اگر حذف خودکار برای حفظ فضای کافی دیسک کافی نیست، با پشتیبانی تماس بگیرید تا درباره حذف دستی نشانه‌ها برای بازیابی فضا اطلاعاتی کسب کنید.
فشرده سازی داده ها توصیه می‌کنیم استراتژی فشرده‌سازی در فضاهای کلیدی را به
LeveledCompactionStrategyتغییر دهید، که استراتژی‌های استفاده بهتر از دیسک را نسبت بهSizeTieredCompactionStrategyپیش‌فرض ارائه می‌دهد. به استراتژی تراکم سطحی مراجعه کنید.
توجه: هنگامی که Cassandra فشرده سازی داده ها را انجام می دهد، می تواند مقدار قابل توجهی از چرخه CPU و حافظه را بگیرد. اما پس از تکمیل تراکم، استفاده از منابع باید به حالت عادی بازگردد. می‌توانید فرمان 'Nodetool compactionstats' روی هر گره اجرا کنید تا بررسی کنید که فشرده‌سازی در حال اجرا است یا خیر. خروجی compactionstats به شما اطلاع می دهد که آیا فشرده سازی های معلقی برای اجرا وجود دارد و زمان تخمین زده شده برای تکمیل.