Genel olarak, iyi tasarlanmış bir kümeye yıllarca dokunulmadan yaşayabilir. Yıllarca el ele tutuşan kümelerim vardı. Ancak, bazı yönergeler aşağıdadır:
İzleme son derece önemlidir:
1) Gecikmeleri izleyin. Gecikmeleri takip etmek için merkez merkezini veya en sevdiğiniz metrik araçlarını kullanın. Artan gecikmeler, GC duraklamaları (okuma iş yüklerinde yazma iş yüklerinden daha yaygın), kararlı sorunlar ve benzerleri de dahil olmak üzere ortaya çıkan sorunların işaretleri olabilir.
2) Sabit sayıları izleyin. Sıkıştırmayı aşarsanız SSTable sayıları artacaktır (her sstable tam olarak bir kez yazılır - silme işlemleri, eski sstable'ları sıkıştırma yoluyla yeni sstables'lara birleştirerek işlenir).
3) Düğüm durumu değişikliklerini izleyin (yukarı / aşağı, vb.). Düğümlerin çırpıldığını görürseniz, normal olmadığı için araştırın.
4) Disk kullanımınızı takip edin - geleneksel olarak% 50'nin altında kalmanız gerekir (özellikle STCS sıkıştırması kullanıyorsanız).
Düzenli olarak yapmanız ve yapmamanız gereken bazı temel şeyler vardır:
1) Açıkça çalıştırmayın nodetool compact. Bunu yaptığınızı söylüyorsunuz, bu ölümcül değil, ancak çok büyük sstables oluşturuyor ve bu da ileriye doğru sıkıştırmaya katılma olasılığı daha düşük. Çalıştırmaya devam etmeniz gerekmez, ancak bazen silinen / üzerine yazılan verilerden kurtulmanıza yardımcı olabilir.
2) nodetool repairgenellikle her önerilir gc_grace_seconds(varsayılan olarak 10 gün). Bunun daha az önemli olduğu iş yükleri vardır - onarım GEREKTİRMENİN en büyük nedeni, silme işaretleyicilerinin ( tombstones) sürelerinin dolmasından önce iletildiğinden emin olmaktır (silme gerçekleştiğinde gc_grace_secondsbir düğüm kapalıysa, bu veriler geri dönebilir) onarım olmadan!). Silme işlemlerini gerçekleştirmezseniz ve yeterli tutarlılık düzeyiyle (örneğin QUORUM'da okur ve yazar) sorgu yaparsanız, tamirat olmadan bir hayat yaşayabilirsiniz.
3) Onarım yapacaksanız, artımlı onarım kullanmayı düşünün ve her seferinde küçük aralıkları onarın.
4) Sıkıştırma stratejileri önemlidir - çok fazla. STCS yazma için harika, LCS okuma için harika. DTCS'nin bazı tuhaflıkları var.
5) Veri modelleri önemlidir - RDBMS / SQL ortamları gibi, unindexed sorgular büyük tablolara çarptığında sorun yaşar gibi, Cassandra çok büyük satırlar / bölümler ile sorunlu olabilir.
6) Anlık görüntüler ucuzdur. Çok ucuz. Neredeyse anında, sadece sabit bağlantılar, hemen hemen hiçbir disk alanına mal olmazlar. Sürümleri, özellikle büyük sürümleri yükseltmeden önce anlık görüntüyü kullanın.
7) Silme işlemlerine dikkat edin. # 2'de ima edildiği gibi, delete diskte daha fazla veri oluşturur ve AT LEAST için serbest bırakmaz gc_grace_seconds.
Diğer her şey başarısız olduğunda:
Prod'daki Cassandra'nın herhangi bir büyüklükteki kümeyi yönetmek için özel bir kafa gerektirdiğini öneren makaleler gördüm - bunun mutlaka doğru olduğunu bilmiyorum, ancak endişeleniyorsanız, bir üçüncü taraf danışmanı (TheLastPickle, Pythian) kiralamak isteyebilirsiniz ) veya içinizin rahat etmesi için bir destek sözleşmesi (Datastax) almanız gerekir.