Redis CONFIG GET, CONFIG SET ve CONFIG REWRITE Rehberi

CONFIG GET: ayarları desenle okumak

CONFIG GET bir ya da daha çok argüman alır ve her argüman glob tarzı bir desendir. Desenlerden herhangi biriyle eşleşen her ayar, ad ve değer çifti olarak döner. RESP2'de yanıt düz bir dizi, RESP3'te bir map (eşleme) yapısıdır. Tüm ayarları görmek için CONFIG GET * yazmanız yeterlidir; belge de desteklenen parametrelerin listesini almak için bu yolu gösterir. Döndürülen her parametrenin anlamı, redis.conf dosyasındaki aynı adlı yönergeyle aynıdır.

redis> config get *max-*-entries* maxmemory
 1) "maxmemory"
 2) "0"
 3) "hash-max-listpack-entries"
 4) "512"
 5) "hash-max-ziplist-entries"
 6) "512"
 7) "set-max-intset-entries"
 8) "512"
 9) "zset-max-listpack-entries"
10) "128"
11) "zset-max-ziplist-entries"
12) "128"

Bu belge örneğinden üç şey çıkar. Birincisi, tek komutta hem desen hem tam ad kullanabilirsiniz. İkincisi, maxmemory değerinin 0 olması bellek sınırı konmadığı anlamına gelir; bunun ne demek olduğu maxmemory ve eviction yazısında anlatılıyor. Üçüncüsü, çıktıda hash-max-listpack-entries ile hash-max-ziplist-entries gibi eski ve yeni adlar yan yana görünebilir; Redis 8.10 sürüm notlarında da CONFIG SET için birincil ad ve takma ad ayrımından söz edilir. Kendi betiklerinizde güncel adı kullanın.

Argümansız CONFIG GET göndermek bir hatadır. Belgedeki hata sayfası mesajı şöyle gösterir; dikkat ederseniz komut adı config|get biçiminde, alt komutuyla birlikte yazılır:

> CONFIG GET
(error) ERR wrong number of arguments for 'config|get' command

CONFIG SET: çalışırken ayar değiştirmek

CONFIG SET bir ya da daha çok parametre değer çifti alır ve sunucuyu yeniden başlatmadan yeniden yapılandırır. Ayarlanan değer hemen yüklenir ve bir sonraki komuttan itibaren etkili olur. Başarılı olduğunda basit metin yanıtı OK, aksi hâlde bir hata döner. Hangi parametrelerin desteklendiğini yine CONFIG GET * ile görürsünüz.

redis> CONFIG SET slowlog-log-slower-than 0
OK

Bu örnek SLOWLOG GET belgesinden alınmıştır: eşik sıfıra çekildiğinde her komut yavaş komut günlüğüne yazılır. Test için kullanışlıdır, ancak yoğun bir sunucuda günlüğü hızla doldurur; ayrıntı SLOWLOG ve latency izleme yazısında. Aynı komutla birden fazla çift de verebilirsiniz; zaman serisi yapılandırma sayfasındaki CONFIG SET ts-ignore-max-time-diff 10 ts-ignore-max-val-diff 0.1 örneği iki parametreyi tek seferde ayarlar.

CONFIG SET kalıcılık modunu da değiştirebilir. CONFIG SET appendonly yes komutu, bellekteki veri kümesinden ilk append-only dosyasını üretmek için bir arka plan süreci başlatır ve sonraki tüm yazma komutlarını bu dosyaya ekler; sonuç, AOF açık başlatılmış bir sunucuyla aynıdır. Belge, AOF ile RDB anlık görüntülerinin birbirini dışlamadığını, ikisinin birlikte açık olabileceğini de belirtir. RDB ve AOF kavramlarının kendisi Redis nedir yazısında, yedek alma komutları BGSAVE ve BACKUP yazısında anlatılıyor.

CONFIG SET appendonly yes

Belgelerde çalışırken değiştirilebildiği yazan ayarlar

CONFIG SET sayfası parametreleri tek tek listelemez; hangi ayarın ne işe yaradığı ilgili konu sayfalarında anlatılır. Aşağıdaki tablo, belgelerde CONFIG SET ile çalışırken değiştirilebildiği açıkça yazan ayarları ve ayrıntının hangi yazıda olduğunu toplar. Değer örnekleri yalnızca belgelerde geçenlerdir.

Tablodaki yazılar: maxmemory ve eviction, CLIENT LIST ve CLIENT KILL, keyspace notifications, Lua script, SLOWLOG ve latency, ACL, OOM, MISCONF, READONLY ve yedek alma. Bu ayarların varsayılan değerlerini ve geçerli aralıklarını kendi sunucunuzda CONFIG GET ile okuyun; sürümden sürüme değişebilirler.

Redis 8.0 ile Redis Open Source, zaman serisi ve olasılıksal veri yapılarının parametrelerini de normal Redis parametreleri gibi yönetmeye başladı: bunlar redis.conf içine yazılabilir, uygun olanlar CONFIG SET ile değiştirilebilir ve CONFIG REWRITE ile kalıcı hâle getirilebilir. Zaman serisi sayfası, CONFIG SET ile ya da yapılandırma dosyasına elle eklenen bir değerin modül yükleme argümanlarıyla verilen değerin önüne geçtiğini belirtir.

Değer hemen geçerli, etkisi her zaman hemen değil

CONFIG SET değeri anında yükler, ama bazı ayarlar mevcut veriye ancak o veri bir sonraki kez yazıldığında uygulanır. Hash belgesi, Redis 8.10 ile gelen kompakt hash dönüşüm ayarlarının (hash-min-template-entries, hash-max-template-entries) hash-max-listpack-entries gibi tembel çalıştığını açıkça söyler: değişiklik belirli bir hash'e, siz komutu çalıştırdığınız anda değil, o hash'e yapılan bir sonraki yazmada uygulanır. Bu yüzden bir kodlama eşiğini değiştirdikten sonra OBJECT ENCODING çıktısının hemen değişmemesi normaldir; kodlamaların ayrıntısı bellek kullanımı yazısında.

Benzer şekilde maxmemory değerini düşürmek, sunucunun hemen bellek boşaltacağı anlamına gelmez; eviction belgesine göre Redis bellek kullanımını yeni veri ekleyen bir komut çalıştığında kontrol eder. Bir ayarın etkisini ölçmek istiyorsanız değiştirdikten sonra ilgili INFO alanlarını izleyin.

CONFIG REWRITE: değişikliği redis.conf dosyasına yazmak

CONFIG REWRITE, sunucunun başlatıldığı redis.conf dosyasını, o anki yapılandırmayı yansıtacak en küçük değişikliklerle yeniden yazar. Belge yeniden yazmanın son derece tutucu yapıldığını anlatır:

• Orijinal dosyadaki yorumlar ve genel yapı mümkün olduğunca korunur.
• Dosyada zaten bulunan bir seçenek, aynı satır numarasında yeniden yazılır.
• Dosyada olmayan ama varsayılan değerinde olan bir seçenek eklenmez.
• Dosyada olmayan ve varsayılandan farklı bir değere sahip seçenek dosyanın sonuna eklenir.
• Artık kullanılmayan satırlar boşaltılır; örneğin birden çok save satırınız vardı ve RDB'yi kapattıysanız bu satırların hepsi boşaltılır.

Dosya bir nedenle silinmişse CONFIG REWRITE onu sıfırdan oluşturabilir. Ancak sunucu hiç yapılandırma dosyası olmadan başlatıldıysa komut yalnızca hata döndürür. Sunucunun hangi dosyayla başladığını INFO server çıktısındaki config_file alanından, hangi çalıştırılabilir dosyanın çalıştığını executable alanından görebilirsiniz.

Yeniden yazma atomiktir: dosyanın her zaman tutarlı kalması, yani hata ya da çökme durumunda ya eski ya yeni dosyanın elinizde olması için Redis içeriği, en az eski dosya kadar büyük tek bir write(2) çağrısıyla yazar. Gerekirse yorum biçiminde dolgu ekler ve ardından dosyayı keserek bu dolguyu kaldırır.

Uygulamalı örnek: bellek sınırı koyup kalıcı yapmak

Önbellek olarak kullanılan bir sunucuya 100 MB sınır koymak ve bunu yeniden başlatmadan sonra da korumak istediğinizi düşünelim. Aşağıdaki sıra belgelerdeki komutlarla yazılmış kendi örneğimizdir, bu yüzden yanıt satırlarını göstermiyoruz.

CONFIG GET maxmemory*
CONFIG SET maxmemory 100mb
CONFIG GET maxmemory
INFO server
CONFIG REWRITE

İlk komut maxmemory ile başlayan tüm ayarları (sınır, politika, örnek sayısı gibi) ad ve değer çiftleri olarak döndürür. İkinci komut başarılıysa OK döner ve sınır hemen geçerli olur. Üçüncü komutla yeni değerin gerçekten yüklendiğini doğrularsınız; INFO memory bölümündeki maxmemory_human alanı aynı değeri okunabilir biçimde gösterir. INFO server çıktısındaki config_file alanı boşsa sunucu yapılandırma dosyasız başlamıştır ve son adım hata verecektir. Dosya varsa CONFIG REWRITE başarıyla OK döndürür ve maxmemory satırı dosyada güncellenir ya da sona eklenir.

Sınır koymak tek başına yetmez; sınıra ulaşıldığında ne olacağını maxmemory-policy belirler. OOM hata sayfasına göre varsayılan politika noeviction olduğundan sınır dolduğunda yeni veri ekleyen komutlar hata alır. Önbellek senaryosu için politika seçimi eviction politikaları yazısında anlatılıyor.

CONFIG RESETSTAT ve CONFIG HELP

CONFIG RESETSTAT, INFO ve LATENCY HISTOGRAM komutlarının raporladığı istatistikleri sıfırlar ve OK döndürür. Belgedeki (tam olmayan) listeye göre sıfırlananlar arasında keyspace isabet ve ıskaları, süresi dolan anahtar sayısı, komut ve hata istatistikleri, alınan, reddedilen ve çıkarılan bağlantı sayıları, kalıcılık istatistikleri ve aktif birleştirme (defragmentation) istatistikleri vardır. INFO belgesi, çok fazla hata nedeniyle devre dışı kalan errorstats bölümünün de bu komutla sıfırlanabileceğini söyler.

Bir değişikliğin etkisini temiz bir başlangıçtan ölçmek istediğinizde işe yarar: örneğin eviction politikasını değiştirdikten sonra keyspace_hits ve keyspace_misses sayaçlarını sıfırlayıp yeni isabet oranını izleyebilirsiniz. Ancak bu sayaçları dışarıdan toplayan bir izleme sisteminiz varsa sıfırlama, grafiklerde ani düşüş olarak görünür. CONFIG HELP ise alt komutları ve kısa açıklamalarını bir dizi olarak döndürür.

Cluster ve replikalarda CONFIG

CONFIG SET yalnızca komutu aldığı sunucuyu değiştirir. Zaman serisi yapılandırma sayfası, cluster içinde CONFIG SET ve CONFIG REWRITE komutlarını her düğümde ayrı ayrı çalıştırmanız gerektiğini açıkça yazar. Komut ipuçları (command tips) sayfası da CONFIG SET komutunu, istemcinin birincil ve replika tüm düğümlerde çalıştırması gereken komutlara örnek olarak verir; yanıtların birleştirilmesinde tek bir hata yanıtı bile sonucu hatalı sayar. Cluster kavramları cluster hash slot yazısında.

Canlı sunucuda güvenli kullanım

config komutu ACL CAT dangerous listesinde yer alır. Uygulama kullanıcılarına bu komutu vermeyin; izleme aracına yalnızca okuma için +config|get verip CONFIG SET yetkisini yöneticiye bırakın. Alt komut düzeyinde engelleme Redis 7.0 ve sonrasında -config|set biçimiyle yapılabilir; kural sözdizimi ACL yazısında.

DENIED hatasının metni, protected mode'u kapatmak için CONFIG SET protected-mode no komutunu seçeneklerden biri olarak sayar. Aynı belge en güvenli çözümün şifre koymak olduğunu söyler ve protected mode'u kapatmayı yalnızca güvenilir bir ağda, sunucunun internetten erişilemediğinden emin olduğunuz durumlarla sınırlar. Bu yazıda bu ayarı değiştirmeyi önermiyoruz; şifre için belgedeki komut şudur:

> CONFIG SET requirepass <password>
OK

Şifrenin yeniden başlatmadan sonra da geçerli olması için aynı değeri yapılandırma dosyasına yazmanız gerekir; CONFIG REWRITE bunun bir yoludur. Ağ katmanında erişimi kısıtlamak için güvenlik duvarı yazısına bakın.

Sık yapılan hatalar

• CONFIG SET sonrası CONFIG REWRITE çalıştırmamak: değişiklik yalnızca bellektedir ve yeniden başlatmada kaybolur.
• Yapılandırma dosyası olmadan başlatılmış sunucuda CONFIG REWRITE beklemek: komut hata döndürür. INFO server çıktısındaki config_file alanına bakın.
• Cluster'da tek düğümü değiştirmek: CONFIG SET ve CONFIG REWRITE her düğümde ayrı çalıştırılmalıdır.
• Kodlama eşiklerini değiştirince mevcut anahtarların hemen dönüşmesini beklemek: bu tür ayarlar ilgili anahtara bir sonraki yazmada uygulanır.
• CONFIG GET çıktısını sabit sırada varsaymak: çıktı RESP2'de ad ve değer çiftlerinden oluşan bir dizi, RESP3'te map yapısıdır; adla eşleştirerek okuyun.
• CONFIG RESETSTAT ile izleme sayaçlarını habersizce sıfırlamak.

Sık Sorulan Sorular

CONFIG SET ile yaptığım değişiklik ne zaman geçerli olur?

Belgeye göre ayarlanan değer hemen yüklenir ve bir sonraki çalıştırılan komuttan itibaren etkili olur. Bazı ayarların mevcut veriye etkisi ise ilgili anahtara bir sonraki yazmayı bekler.

Değişiklik yeniden başlatmada neden kayboldu?

CONFIG SET yalnızca çalışan süreci değiştirir. Kalıcı olması için CONFIG REWRITE ile redis.conf dosyasına yazmanız ya da dosyayı elle düzenlemeniz gerekir.

Tüm ayarları nasıl listelerim?

CONFIG GET * desteklenen tüm parametreleri ad ve değer çiftleri olarak döndürür. Belirli bir grubu görmek için CONFIG GET maxmemory* gibi bir desen kullanın; birden fazla desen de verebilirsiniz.

Sunucunun hangi redis.conf dosyasını kullandığını nasıl bulurum?

INFO server çıktısındaki config_file alanı yapılandırma dosyasının yolunu gösterir. Alan boşsa sunucu dosyasız başlatılmıştır ve CONFIG REWRITE hata verir.

Uygulama kullanıcısının ayar değiştirmesini nasıl engellerim?

ACL ile kullanıcıya -@dangerous kuralını verin ya da yalnızca -config|set ile alt komutu kapatın. Okuma ihtiyacı olan izleme araçlarına +config|get yeterlidir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Redis öğrenme rehberi · maxmemory ve eviction politikaları · Redis ACL · INFO komutu ve sunucu izleme · SLOWLOG ve latency izleme