MISCONF Redis, RDB anlık görüntülerini kaydetmek için yapılandırıldı

Redis ( SET foo bar) için yazma sırasında Aşağıdaki hatayı alıyorum:

MISCONF Redis, RDB anlık görüntülerini kaydetmek için yapılandırılmıştır, ancak şu anda diskte devam edememektedir. Veri kümesini değiştirebilecek komutlar devre dışı bırakılır. Hatayla ilgili ayrıntılar için lütfen Redis günlüklerini kontrol edin.

Temel olarak, sorunun redis'in diske veri kaydedemediğini, ancak problemden nasıl kurtulacağını bilmediğini anlıyorum.

Ayrıca aşağıdaki soru aynı soruna sahiptir, uzun zaman önce cevapsız ve muhtemelen sorunu çözme girişimi olmadan terk edilmiştir.

Hatayla karşılaşırsanız ve bazı önemli veriler çalışan redis örneğinde silinemezse ( rdbdosya veya dizinin izinleriyle ilgili sorunlar yanlış veya disk alanınız tükeniyorsa), her zamanrdb başka bir yere yazılmak dosyayı .

Kullanarak redis-cli, böyle bir şey yapabilirsiniz:

CONFIG SET dir /tmp/some/directory/other/than/var
CONFIG SET dbfilename temp.rdb

Bundan sonra BGSAVE, verilerin rdbdosyaya yazıldığından emin olmak için bir komut yürütmek isteyebilirsiniz . Eğer yürütmek zaman emin olun INFO persistence, bgsave_in_progresszaten 0ve rdb_last_bgsave_statusbir ok. Bundan sonra, oluşturulan rdbdosyayı güvenli bir yere yedeklemeye başlayabilirsiniz .

Kullanarak redis-cli, anlık görüntüyü kaydetmeye çalışarak durdurabilirsiniz:

config set stop-writes-on-bgsave-error no

Bu hızlı bir çözümdür, ancak kullandığınız verileri önemsiyorsanız, bgsave'nin neden ilk etapta başarısız olduğunu kontrol etmelisiniz.

Düşük bellek nedeniyle bgsave işlemi sırasında hatalar olabilir. Bunu deneyin (redis background save SSS'den)

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

Bu hata, BGSAVE başarısız olduğu için oluşur. BGSAVE sırasında Redis, verileri diske kaydetmek için bir alt süreç çatallar. Her ne kadar BGSAVE'nin arızalanmasının kesin nedeni günlüklerden (genellikle /var/log/redis/redis-server.loglinux makinelerinde) kontrol edilebilir, ancak çatal bellek ayıramadığından BGAVE başarısız olur. Çoğu zaman çatal, işletim sistemi tarafından çakışan bir optimizasyon nedeniyle (makinede yeterli RAM olmasına rağmen) bellek ayırmayı başaramaz.

Redis SSS sayfasından okunabileceği gibi :

Redis arka plan kaydetme şeması, modern işletim sistemlerinde çatalın yazma üzerine yazma semantiğine dayanır: Ebeveynin tam kopyası olan çatalları (bir alt işlem oluşturur) redis. Alt işlem DB'yi diske döker ve son olarak çıkar. Teoride, çocuk ebeveynin kopya olduğu kadar bellek kullanmalıdır, ancak aslında çoğu modern işletim sistemi tarafından uygulanan yazma üzerine yazma semantiği sayesinde ebeveyn ve çocuk süreci ortak bellek sayfalarını paylaşacaktır. Bir sayfa yalnızca alt öğede veya üst öğede değiştiğinde çoğaltılır. Teoride, alt süreç kaydedilirken tüm sayfalar değişebileceğinden, Linux önceden çocuğun ne kadar bellek alacağını söyleyemez, bu nedenle overcommit_memory ayarı sıfır çatal olarak ayarlanırsa, boş RAM fazla olmadığı sürece başarısız olur. tüm üst bellek sayfalarını gerçekten çoğaltmak için gerekli,

Overcommit_memory değerini 1 olarak ayarlamak, Linux'un daha iyimser bir tahsis tarzında çatalı rahatlatacağını ve gerçekleştireceğini söylüyor ve bu Redis için gerçekten istediğiniz şey.

Redis, işletim sisteminin diske yazmayı düşündüğü kadar belleğe ihtiyaç duymaz, bu nedenle çatalı önceden etkin bir şekilde bozabilir.

Bunu çözmek için şunları yapabilirsiniz:

Değiştirin /etc/sysctl.confve ekleyin:

vm.overcommit_memory=1

Sonra sysctl ile yeniden başlatın:

FreeBSD'de:

sudo /etc/rc.d/sysctl reload

Linux'ta:

sudo sysctl -p /etc/sysctl.conf

Redis sunucunuzu yeniden başlatın.

• MacOS (hazırlama) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Tür services.msc, Enter-> Ara'yı Redistıklayın ve tıklayın restart.

Şahsen Brew ( brew upgrade) ile redis yükselttikten sonra bu sorunu vardı . Dizüstü bilgisayarı yeniden başlattıktan sonra hemen çalıştı.

bir linux makinesinde çalışıyorsanız, veritabanının dosya ve klasör izinlerini de yeniden kontrol edin.

Db ve yolu aşağıdaki yollarla elde edilebilir:

içinde redis-cli:

CONFIG GET dir

CONFIG GET Instagram Hesabındaki Resim ve Videoları dbfilename

ve komut satırında ls -l. Dizin izinleri 755 , dosya izinleri 644 olmalıdır . Ayrıca, normal olarak redis-server kullanıcı olarak yürütülür redis, bu nedenle kullanıcıya redisklasöre sahipliğini vermek de iyidir sudo chown -R redis:redis /path/to/rdb/folder. Bu cevap hakkında açıklamalar, burada .

Sorunu kontrol ettiğiniz için herkese teşekkürler, görünüşe göre hata sırasında üretildi bgsave.

Benim config set stop-writes-on-bgsave-error noiçin bir mermi yazmak ve Redis'i yeniden başlatmak sorunu çözdü.

Redis Server'ı, Redis'in yazma izinlerine sahip olduğu bir dizinde başlatın

Yukarıdaki cevaplar sorununuzu kesinlikle çözecektir, ancak gerçekte olan şu:

rdb.dumpDosyayı saklamak için varsayılan konum ./(geçerli dizini gösterir). Bunu redis.confdosyanızda doğrulayabilirsiniz . Bu nedenle, redis sunucusunu başlattığınız dizin bir dump.rdbdosyanın oluşturulacağı ve güncelleneceği yerdir .

Redis sunucusunu, redis'in dump.rdbdosyayı oluşturmak için doğru izinlere sahip olmadığı bir dizinde çalıştırmaya başladığınız anlaşılıyor .

Daha da kötüsü, redis ayrıca verilerin düzgün bir şekilde kaydedilmesini sağlamak için rdb dosyasını oluşturabilene kadar sunucuyu kapatmanıza da izin vermez.

Bu sorunu çözmek için redis-cli, diranahtarı kullanarak etkin redis istemci ortamına gitmeli ve güncellemeli ve değerini proje klasörünüze veya kök olmayan kaydetme izinlerine sahip herhangi bir klasöre ayarlamalısınız. Sonra dosyanın BGSAVEoluşturulmasını çağırmak için çalıştırın dump.rdb.

CONFIG SET dir "/hardcoded/path/to/your/project/folder"
BGSAVE

(Şimdi, dump.rdb dosyasını sunucuyu başlattığınız dizine kaydetmeniz gerekiyorsa , dizinin izinlerini değiştirmeniz için redis'in ona yazabilmesi gerekir. ).

Artık redis sunucusunu kapatabilirsiniz. Yolu kodladığımızı unutmayın. Hardcoding nadiren iyi bir uygulamadır ve redis sunucusunu proje dizininizden başlatmanızı ve dir key back to. / ` Değiştirmenizi önemle tavsiye ederim .

CONFIG SET dir "./"
BGSAVE

Bu şekilde, başka bir proje için yeniden redüksiyona ihtiyaç duyduğunuzda, döküm dosyası sabit kodlu yolun proje dizininde değil, geçerli projenizin dizininde oluşturulur.

MacOS çalıştırıyorsanız ve kısa süre önce Catalina sürümüne geçtiyseniz, bu sayıdabrew services restart redis önerildiği gibi çalıştırmanız gerekebilir .

Bu hatayla karşılaşmıştı ve hatanın disk alanının yeterli olmaması nedeniyle günlükten anlayabilmişti. Benim durumuma eklenen tüm verilere artık gerek yoktu. Bu yüzden FLUSHALL yapmaya çalıştım. Redis-rdb-bgsave işlemi çalıştığından, verilerin FLUSH olmasına da izin vermiyordu. Aşağıdaki adımları izledim ve devam edebildim.

1. Redis istemcisine giriş
2. Yürütme yapılandırma kümesi dur-yazma-on-bgsave-yanılma yok
3. Yürütme FLUSHALL (Veri gerekli değildi saklanan)
4. Yürütme yapılandırma kümesi dur-yazma-on-bgsave yanılma evet

İşlem redis-rdb-bgsave, yukarıdaki adımlardan sonra artık çalışmıyordu.

Benzer bir sorunla karşı karşıya kaldım, bunun arkasındaki ana sebep redis tarafından bellek (RAM) tüketimi oldu. EC2 makinemde 8GB RAM vardı (tüketim için 7.4 mevcut)

Programım çalışırken RAM kullanımı 7,2 GB'a kadar çıkmış ve RAM'de ~ 100MB güçlük çekiyor, bu genellikle MISCONF Redis error ...

RAM tüketimini htopkomutunu kullanarak belirleyebilirsiniz . Htop komutunu çalıştırdıktan sonra Mem niteliğini arayın . Yüksek tüketim gösteriyorsa (benim durumumda olduğu gibi 7.2GB / 7.4GB idi) Örneğin daha büyük Bellek ile yükseltmek daha iyidir. Bu senaryoda kullanmak config set stop-writes-on-bgsave-error nosunucu için bir felaket olacaktır ve sunucuda (varsa) çalışan diğer hizmetlerin bozulmasına neden olabilir. Bu nedenle, config komutundan kaçınmak ve REDIS MAKİNENİZİ YÜKSELTİN .

Bilginize: Bu işi yapmak için htop yüklemeniz gerekebilir :sudo apt-get install htop

Buna bir çözüm daha sisteminizde çalışan diğer RAM ağır hizmet olabilir, sunucunuzda / makinenizde / örneğinizde çalışan diğer hizmetleri kontrol edin ve gerekli değilse durdurun. Makinenizde çalışan tüm hizmetleri kontrol etmek içinservice --status-all

Ve doğrudan config komutunu yapıştıran insanlar için bir öneri, lütfen biraz yeniden arama yapın ve en azından bu tür komutları kullanmadan önce kullanıcıyı uyarın. @Rodrigo'nun yorumunda belirttiği gibi: "Hataları görmezden gelmek hoş görünmüyor."

---GÜNCELLEME---

Ayrıca , belirli bir bellek sınırına ulaşıldığında Redis'in davranışını yapılandırabilir maxmemoryve maxmemory-policytanımlayabilirsiniz. Örneğin, redis mem kullanımının 6GB'ı aşmadığından emin olmak için 6GB bellek sınırını korumak ve en son kullanılan anahtarları DB'den silmek istiyorsam, bu iki parametreyi (redis.conf veya CONFIG SET'te) ayarlayabiliriz. komutu):

maxmemory 6gb
maxmemory-policy allkeys-lru

Buradan bu konuda okuyabileceğiniz bu iki parametre için ayarlayabileceğiniz başka birçok değer vardır: https://redis.io/topics/lru-cache

Daha kalıcı bir düzeltme, 200-250 satırları arasında /etc/redis/redis.conf dosyasına bakmak olabilir.

özellikle

dir ./

olarak değiştirilebilir

dir /home/someuser/redislogfiledirectory

veya tüm kaydetme satırlarını yorumlayabilir ve kalıcılık konusunda endişelenmeyebilirsiniz. (/Etc/redis/redis.conf'daki yorumlara bakın)

Ayrıca unutma

service redis-server stop
service redis-server start

tüm bu cevaplar rdb kaydının neden başarısız olduğunu açıklamaz.

Benim durumum olarak, redis günlüğünü kontrol ettim ve buldum:

14975: M 18 Jun 13: 23: 07.354 # Sinyal 9 ile sonlandırılan arka plan kaydetme

terminalde aşağıdaki komutu çalıştırın:

sudo egrep -i -r 'killed process' /var/log/

görüntüler:

/var/log/kern.log.1:Haziran 18 13:23:07 10-10-88-16 çekirdek: [28152358.208108] Öldürülen süreç 28416 (redis-sunucu) toplam-vm: 7660204kB, anon-rss: 2285492kB, dosya rss 0KB

bu kadar! bu süreç (redd save rdb) OOM katili tarafından öldürüldü

atıfta:

https://github.com/antirez/redis/issues/1886

Linux OOM katili tarafından hangi sürecin öldürüldüğünü bulma

FWIW, bununla karşılaştım ve çözüm kutuya bir takas dosyası eklemekti. Bu yöntemi kullandım: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

Ben de aynı sorunla karşı karşıyaydım. Hem cevaplar (en çok oylanan ve kabul edilen) hem de geçici olarak düzeltildi.

Dahası, config set stop-writes-on-bgsave-error nobu hatayı gözden geçirmek için korkunç bir yoldur, çünkü bu seçeneğin yaptığı, yazma işlemlerinin durdurulduğunu bildirmek ve verileri bir anlık görüntüye yazmadan devam etmek için redis'i durdurmaktır. Bu sadece bu hatayı yok sayıyor. Buna bakın

Ayarı gelince dirde configsen Redis hizmetini yeniden bir kere Redis-cli içinde, bu çok temizlenmezse eder ve aynı hata tekrar açılır edecektir. Varsayılan değeri diriçinde redis.confolduğunu ./ve kök kullanıcı olarak REDIS başlarsanız, o zaman ./olduğunu /dolayısıyla hata yazma izinleri verilmeyen oldukları ve.

En iyi yol, dirparametreyi redis.conf dosyasında ayarlamak ve bu dizine uygun izinleri ayarlamaktır. Debian dağıtımlarının çoğunda/etc/redis/redis.conf

Günümüzde istemciye bu hata iletisini veren Redis yazma erişim sorunları resmi redisliman işçisi konteynırlarında yeniden ortaya çıktı .

Dan Redis resmi redisgörüntü denemeden kaplarda .rdb dosyası yazmak için /databir kök sahip olduğu klasör olduğu gibi, oldukça talihsiz klasörü ve çok kalıcı olmayan bir konumdur (yazılı veri yoktur kaybolur eğer konteyner / pod ) çöker.

Bu nedenle, bir saatlik bir işlem yapılmadığında, rediskapsayıcınızı kök olmayan bir kullanıcı olarak çalıştırdıysanız (örneğin docker run -u 1007, varsayılan olarak değil docker run -u 0), sunucu günlüğünüzde ayrıntılı bir hata iletisi alırsınız (bkz. docker logs redis):

1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error

Yapmanız gereken, kapsayıcı /dataklasörünü harici bir konuma eşlemek (kök olmayan kullanıcının burada: 1007, /tmpana makine gibi yazma erişimine sahip olduğu ), örn:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

O (yazmalıdır resmi liman işçisi görüntünün bir yanlış yapılandırma olduğu Yani /tmpdeğil /data/: Öyle olacağına büyük olasılıkla karşılaşma sadece üretimde ... gecede bazı özellikle sessiz tatil hafta sonu bu "saatli bombayı" üretir)

benim için

config set stop-writes-on-bgsave-error no

ve mac'umu yeniden yüklüyorum, işe yarıyor

AFS disk alanı olan bir sunucu üzerinde çalışırken bu soruna Permission Deniedçarptım, çünkü redis sunucusu kaydetmeye çalıştığında yanıt verdi . Jetonumu yenileyerek bunu çözdüm:

kinit USERNAME_HERE -l 30d && aklog

Docker / Docker-Compose kullanıyorsanız ve dosyaya yazma den REDIS önlemek istiyorsanız, bir Redis yapılandırma oluşturabilir ve bir kabın içine monte

docker.compose.override.yml

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

Sen varsayılan yapılandırma indirebilirsiniz burada

redis.conf dosyasında bu 3 satırı yorumladığınızdan emin olun

save 900 1
save 300 10
save 60 10000

myou kalıcı veri çıkarılması için daha fazla çözüm görüntüleyebilir burada

Benim durumumda oldu çünkü redishızlı bir şekilde kullanarak yeni kurdum . Yani redis kök olarak çalışmıyor. Bu sorunu Hızlı Başlangıç ​​KılavuzuInstalling Redis more properly bölümünün altındaki talimatları izleyerek çözebildim . Bunu yaptıktan sonra, sorun çözüldü ve şimdi kök olarak çalışıyor. Bunu kontrol et.redis

Sonunda pek çok SO sorusuna kafamı vurduktan sonra - benim için @Axel Advento'nun cevabı çalıştı ama birkaç ekstra adımla - hala izin sorunları ile karşı karşıyaydım.
Kullanıcıya geçmek redis, ev dizininde yeni bir dizin oluşturmak ve ardından redis'in dizini olarak ayarlamak zorunda kaldım.

sudo su - redis -s /bin/bash
mkdir redis_dir
redis-cli CONFIG SET dir $(realpath redis_dir)
exit # to logout from redis user (optional)

Benim durumumda disk boş alanıyla ilgiliydi. ( df -hbash komutuyla kontrol edebilirsiniz ) biraz boşluk bıraktığımda bu hata kayboldu.

Redis'i yerel olarak bir Windows makinesinde çalıştırıyorsanız, "yönetici olarak çalıştır" ı deneyin ve çalışıp çalışmadığına bakın. Benimle sorun, Redis'in varsayılan olarak izinleri kısıtlayan "Program Files" klasöründe bulunmasıydı. Olması gerektiği gibi.

Ancak Redis'i otomatik olarak yönetici olarak çalıştırmayın Ona sahip olması gereken daha fazla hak vermek istemezsiniz. Bunu kitapla çözmek istiyorsun.

Bu nedenle, sorunu yönetici olarak çalıştırarak hızlı bir şekilde tanımlayabildik, ancak bu tedavi değil. Muhtemel bir senaryo, Redis'i yazma hakları olmayan bir klasöre koymuş olmanız ve sonuç olarak DB dosyasının aynı konumda depolanmasıdır.

redis.windows.confAşağıdaki konfigürasyonu aramak için ve tuşlarını kullanarak bunu çözebilirsiniz :

    # The working directory.
    #
    # The DB will be written inside this directory, with the filename specified
    # above using the 'dbfilename' configuration directive.
    #
    # The Append Only File will also be created inside this directory.
    #
    # Note that you must specify a directory here, not a file name.
    dir ./

İçin dir ./düzenli okuma / yazma izinlerine sahip olduğunuz bir yolla değiştirin

Ayrıca, içindeki Redis klasörünü tamamen doğru izinlere sahip olduğunu bildiğiniz bir klasöre taşıyabilirsiniz.

Benim için bu sadece kalıcı yeniden veri veri klasöründe bir izin sorunu oldu. Ben verdim:

chmod 777 -Rf data/

Ve işe yarıyor! Sorunu çözdüğünü söylemek için erken olabilir. Ayrıca redis kök olarak yürütülmediğinden şüpheleniyorum, bu yüzden daha fazla anlamak için dockerFile incelemek gerekir.

Herhangi bir işlem yapmadan önce Redis günlüğünüzü kontrol edin. Bu dizideki bazı çözümler Redis verilerinizi silebilir, bu yüzden ne yaptığınıza dikkat edin.

Benim durumumda, makinenin RAM'i bitiyordu . Bu , ana bilgisayarda boş disk alanı kalmadığında da olabilir .

Bu hatanın sunucunuz saldırıya uğradığında göründüğünü lütfen unutmayın. Sadece redis'in '/etc/cron.d/web' dosyasına yazamadığını, burada izinlerin düzeltilmesinden sonra bazı gizleme seçenekleriyle madencilik algoritmasından oluşan yeni bir dosya eklendi.

# on redis 6.0.4 
# if show error 'MISCONF Redis is configured to save RDB snapshots'
# Because redis doesn't have permissions to create dump.rdb file
sudo redis/bin/redis-server 
sudo redis/bin/redis-cli

@Chris tarafından işaret edildiği gibi, problemin hafızanın azalması muhtemeldir. MySQL'e ( innodb_buffer_pool_size) çok fazla RAM ayırdığımızda bunu deneyimlemeye başladık .

Redis ve diğer hizmetler için yeterli RAM olduğundan emin olmak için MySQL'de azalttık innodb_buffer_pool_size.

Benim durumumda, neden diskte çok düşük boş alan (sadece 35 Mb) idi. Aşağıdakileri yaptım -

1. Redis ile ilgili tüm işlemleri durdurdu
2. Yeterli boş alan oluşturmak için diskteki bazı dosyaları silin

3. Redis döküm dosyasını sil (mevcut veri gerekli değilse)

   sudo rm /var/lib/redis/*

4. Mevcut tüm veritabanlarının tüm anahtarlarını sil

   sudo redis-cli flushall

5. tüm kereviz görevlerini yeniden başlatın ve herhangi bir sorun için ilgili günlükleri kontrol edin

chmod ve yeni klasörü seçmelisiniz

chown -R redis ve chmod ...