MISCONF Redis được cấu hình để lưu ảnh chụp nhanh RDB

Trong quá trình ghi vào Redis ( SET foo bar) tôi gặp lỗi sau:

MISCONF Redis được cấu hình để lưu ảnh chụp nhanh RDB, nhưng hiện tại không thể tồn tại trên đĩa. Các lệnh có thể sửa đổi tập dữ liệu bị vô hiệu hóa. Vui lòng kiểm tra nhật ký Redis để biết chi tiết về lỗi.

Về cơ bản tôi hiểu rằng vấn đề là redis không thể lưu dữ liệu trên đĩa, nhưng không biết làm thế nào để thoát khỏi vấn đề.

Ngoài ra câu hỏi sau đây có cùng một vấn đề, nó đã bị bỏ rơi từ lâu và không có câu trả lời và hầu hết có lẽ không có nỗ lực để giải quyết vấn đề.

Trong trường hợp bạn gặp lỗi và một số dữ liệu quan trọng không thể được loại bỏ trong trường hợp redis đang chạy (vấn đề với quyền cho rdbtệp hoặc thư mục của tệp không chính xác hoặc hết dung lượng đĩa), bạn luôn có thể chuyển hướng rdbtệp được ghi ở nơi khác.

Sử dụng redis-cli, bạn có thể làm một cái gì đó như thế này:

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

Sau này, bạn có thể muốn thực thi một BGSAVElệnh để đảm bảo rằng dữ liệu sẽ được ghi vào rdbtệp. Hãy chắc chắn rằng khi bạn thực thi INFO persistence, bgsave_in_progressđã 0và rdb_last_bgsave_statusđang ok. Sau đó, bây giờ bạn có thể bắt đầu sao lưu rdbtệp được tạo ở nơi an toàn.

Sử dụng redis-cli, bạn có thể ngăn nó cố lưu ảnh chụp nhanh:

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

Đây là một cách giải quyết nhanh chóng, nhưng nếu bạn quan tâm đến dữ liệu bạn đang sử dụng, bạn nên kiểm tra để đảm bảo tại sao bssave lại thất bại ngay từ đầu.

Có thể có lỗi trong quá trình bssave do bộ nhớ thấp. Hãy thử điều này (từ redis lưu câu hỏi thường gặp)

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

Lỗi này xảy ra do BGSAVE không thành công. Trong BGSAVE, Redis tạo ra một tiến trình con để lưu dữ liệu trên đĩa. Mặc dù lý do chính xác cho sự thất bại của BGSAVE có thể được kiểm tra từ các bản ghi (thường là /var/log/redis/redis-server.logtrên các máy linux) nhưng rất nhiều lần BGAVE không thành công vì fork không thể phân bổ bộ nhớ. Nhiều lần ngã ba không phân bổ bộ nhớ (mặc dù máy có đủ RAM khả dụng) do hệ điều hành tối ưu hóa xung đột.

Như có thể được đọc từ Redis FAQ :

Lược đồ lưu nền Redis dựa trên ngữ nghĩa sao chép trên ghi trong các hệ điều hành hiện đại: Redis forks (tạo một tiến trình con) là bản sao chính xác của cha mẹ. Quá trình con bỏ DB trên đĩa và cuối cùng thoát ra. Về lý thuyết, đứa trẻ nên sử dụng nhiều bộ nhớ như cha mẹ là một bản sao, nhưng thực sự nhờ vào ngữ nghĩa sao chép được thực hiện bởi hầu hết các hệ điều hành hiện đại, quá trình cha mẹ và con cái sẽ chia sẻ các trang bộ nhớ chung. Một trang sẽ được nhân đôi chỉ khi nó thay đổi ở trẻ hoặc ở cha mẹ. Vì về lý thuyết, tất cả các trang có thể thay đổi trong khi quá trình con đang lưu, Linux không thể biết trước bộ nhớ của trẻ sẽ chiếm bao nhiêu bộ nhớ, vì vậy nếu cài đặt overcommit_memory được đặt thành zero fork sẽ thất bại trừ khi có nhiều RAM miễn phí như cần thiết để thực sự sao chép tất cả các trang bộ nhớ cha,

Đặt overcommit_memory thành 1 cho biết Linux để thư giãn và thực hiện fork theo cách phân bổ lạc quan hơn, và đây thực sự là những gì bạn muốn cho Redis.

Redis không cần nhiều bộ nhớ như HĐH nghĩ rằng nó ghi vào đĩa, do đó có thể thất bại trước ngã ba.

Để giải quyết vấn đề này, bạn có thể:

Sửa đổi /etc/sysctl.confvà thêm:

vm.overcommit_memory=1

Sau đó khởi động lại sysctl với:

Trên FreeBSD:

sudo /etc/rc.d/sysctl reload

Trên Linux:

sudo sysctl -p /etc/sysctl.conf

Khởi động lại máy chủ redis của bạn.

• macOS (bia) : brew services restart redis.
• Linux: sudo service redis restart /sudo systemctl restart redis
• Windows: Windows + R-> Gõ services.msc, Enter-> Tìm kiếm Redissau đó nhấp vào restart.

Cá nhân tôi đã gặp vấn đề này sau khi nâng cấp redis với Brew ( brew upgrade). Sau khi khởi động lại máy tính xách tay, nó ngay lập tức hoạt động.

trong trường hợp bạn đang làm việc trên một máy linux, cũng kiểm tra lại các quyền của tệp và thư mục của cơ sở dữ liệu.

Db và đường dẫn đến nó có thể được lấy thông qua:

trong redis-cli:

CONFIG NHẬN dir

XÁC NHẬN tên tệp

và trong dòng lệnh ls -l. Các quyền cho thư mục phải là 755 và các quyền cho tệp phải là 644 . Ngoài ra, thông thường redis-server thực thi với tư cách là người dùng redis, do đó, cũng rất tốt để cung cấp cho người dùng redisquyền sở hữu thư mục bằng cách thực thi sudo chown -R redis:redis /path/to/rdb/folder. Điều này đã được xây dựng trong câu trả lời ở đây .

Cảm ơn tất cả mọi người đã kiểm tra vấn đề, rõ ràng lỗi đã được tạo ra trong thời gian bgsave.

Đối với tôi, gõ config set stop-writes-on-bgsave-error novào một cái vỏ và khởi động lại Redis đã giải quyết vấn đề.

Khởi động Redis Server trong một thư mục nơi Redis có quyền ghi

Các câu trả lời ở trên chắc chắn sẽ giải quyết vấn đề của bạn, nhưng đây là những gì thực sự đang diễn ra:

Vị trí mặc định để lưu trữ rdb.dumptệp là ./(biểu thị thư mục hiện tại). Bạn có thể xác minh điều này trong redis.conftập tin của bạn . Do đó, thư mục nơi bạn khởi động máy chủ redis là nơi một dump.rdbtệp sẽ được tạo và cập nhật.

Có vẻ như bạn đã bắt đầu chạy máy chủ redis trong một thư mục mà redis không có quyền chính xác để tạo dump.rdbtệp.

Để làm cho vấn đề tồi tệ hơn, redis cũng có thể sẽ không cho phép bạn tắt máy chủ cho đến khi có thể tạo tệp rdb để đảm bảo lưu dữ liệu đúng cách.

Để giải quyết vấn đề này, bạn phải vào môi trường máy khách hoạt động lại bằng cách sử dụng redis-clivà cập nhật dirkhóa và đặt giá trị của nó vào thư mục dự án của bạn hoặc bất kỳ thư mục nào không có quyền root để lưu. Sau đó chạy BGSAVEđể gọi việc tạo dump.rdbtập tin.

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

(Bây giờ, nếu bạn cần lưu tệp dump.rdb trong thư mục mà bạn đã khởi động máy chủ, thì bạn sẽ cần thay đổi quyền cho thư mục để redis có thể ghi vào nó. Bạn có thể tìm kiếm stackoverflow để biết cách làm điều đó. ).

Bây giờ bạn có thể tắt máy chủ redis. Lưu ý rằng chúng tôi đã mã hóa đường dẫn. Hardcoding hiếm khi là một cách thực hành tốt và tôi khuyên bạn nên khởi động máy chủ redis từ thư mục dự án của bạn và thay đổi dir key back to. / `.

CONFIG SET dir "./"
BGSAVE

Theo cách đó khi bạn cần làm lại cho một dự án khác, tệp kết xuất sẽ được tạo trong thư mục dự án hiện tại của bạn chứ không phải trong thư mục dự án của đường dẫn được mã hóa cứng.

Nếu bạn đang chạy MacOS và gần đây đã nâng cấp lên Catalina, bạn có thể cần chạy brew services restart redisnhư được đề xuất trong vấn đề này .

Đã gặp phải lỗi này và có thể nhận ra từ nhật ký rằng lỗi là do không gian đĩa không đủ. Tất cả dữ liệu được chèn trong trường hợp của tôi không còn cần thiết nữa. Vì vậy, tôi đã cố gắng để BỎ. Vì quá trình redis-rdb-bssave đang chạy, nên nó cũng không cho phép XÓA dữ liệu. Tôi làm theo các bước dưới đây và có thể tiếp tục.

1. Đăng nhập vào máy khách
2. Thực thi cấu hình thiết lập stop-write-on-bssave-error no
3. Thực thi FLUSHALL (Không cần lưu trữ dữ liệu)
4. Thực thi cấu hình thiết lập stop-write-on-bssave-error yes

Quá trình redis-rdb-bssave không còn chạy sau các bước trên.

Tôi đã đối mặt với vấn đề tương tự, lý do chính đằng sau điều này là mức tiêu thụ bộ nhớ (RAM) của redis. Máy EC2 của tôi có RAM 8GB (arounf 7.4 có sẵn để tiêu thụ)

Khi chương trình của tôi đang chạy, mức sử dụng RAM lên tới 7,2 GB, hầu như không có ~ 100 MB RAM, điều này thường kích hoạt MISCONF Redis error ...

Bạn có thể xác định mức tiêu thụ RAM bằng htoplệnh. Tìm thuộc tính Mem sau khi chạy lệnh htop. Nếu nó cho thấy mức tiêu thụ cao (như trong trường hợp của tôi thì đó là 7.2GB / 7.4GB) Tốt hơn hết là nâng cấp thể hiện với Bộ nhớ lớn hơn. Trong trường hợp này, việc sử dụng config set stop-writes-on-bgsave-error nosẽ là một thảm họa cho máy chủ và có thể dẫn đến phá vỡ các dịch vụ khác đang chạy trên máy chủ (nếu có). Vì vậy, tốt hơn hết là tránh lệnh config và NÂNG CẤP MÁY GIẢM GIÁ CỦA BẠN .

FYI: Bạn có thể cần phải cài đặt htop để thực hiện công việc này:sudo apt-get install htop

Một giải pháp nữa cho vấn đề này có thể là một số dịch vụ nặng RAM khác đang chạy trên hệ thống của bạn, kiểm tra dịch vụ khác đang chạy trên máy chủ / máy / thể hiện của bạn và dừng nó nếu không cần thiết. Để kiểm tra tất cả các dịch vụ đang chạy trên máy của bạn, hãy sử dụngservice --status-all

Và một gợi ý cho những người dán trực tiếp lệnh config, vui lòng tìm kiếm lại một chút và ít nhất cảnh báo người dùng trước khi sử dụng các lệnh đó. Và như @Rodrigo đã đề cập trong bình luận của mình: "Thật không hay khi bỏ qua các lỗi."

--- CẬP NHẬT ---

YOu cũng có thể định cấu hình maxmemoryvà maxmemory-policyxác định hành vi của Redis khi đạt đến giới hạn bộ nhớ cụ thể. Ví dụ: nếu tôi muốn giữ giới hạn bộ nhớ là 6GB và xóa các khóa được sử dụng gần đây nhất khỏi DB để đảm bảo rằng việc sử dụng memis không vượt quá 6GB, thì chúng ta có thể đặt hai tham số này (trong redis.conf hoặc CONFIG SET chỉ huy):

maxmemory 6gb
maxmemory-policy allkeys-lru

Có rất nhiều giá trị khác mà bạn có thể đặt cho hai tham số này bạn có thể đọc về điều này từ đây: https://redis.io/topics/lru-cache

Một sửa chữa lâu dài hơn có thể là tìm trong /etc/redis/redis.conf xung quanh các dòng 200-250, có các cài đặt cho các tính năng rdb, đó không phải là một phần của sự phục hồi trong 2.x ngày.

đáng chú ý

dir ./

có thể thay đổi thành

dir /home/someuser/redislogfiledirectory

hoặc bạn có thể nhận xét tất cả các dòng lưu, và không lo lắng về sự kiên trì. (Xem các bình luận trong /etc/redis/redis.conf)

Ngoài ra, đừng quên

service redis-server stop
service redis-server start

tất cả những câu trả lời đó không giải thích lý do tại sao việc lưu rdb không thành công.

như trường hợp của tôi, tôi đã kiểm tra nhật ký redis và tìm thấy:

14975: M 18 tháng 6 13: 23: 07.354 # Lưu nền bị chấm dứt bởi tín hiệu 9

chạy lệnh sau trong terminal:

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

nó hiển thị:

.varvar tệp-rss: 0kB

chính là nó quá trình này (redis save rdb) bị giết bởi OOM killer

đề cập đến:

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

Tìm ra quá trình đã bị giết bởi kẻ giết người OOM Linux

FWIW, tôi đã gặp phải vấn đề này và giải pháp đơn giản là thêm một tệp hoán đổi vào hộp. Tôi đã sử dụng phương pháp này: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ub Ubuntu-14-04

Tôi cũng đã đối mặt với cùng một vấn đề. Cả hai câu trả lời (câu trả lời nhiều nhất và câu trả lời được chấp nhận) chỉ đưa ra cách khắc phục tạm thời cho cùng.

Hơn nữa, đây config set stop-writes-on-bgsave-error nolà một cách khủng khiếp để xem xét lỗi này, vì những gì tùy chọn này làm là ngăn chặn việc thông báo rằng việc ghi đã bị dừng và tiếp tục mà không ghi dữ liệu trong ảnh chụp nhanh. Điều này chỉ đơn giản là bỏ qua lỗi này. Tham khảo cái này

Đối với cài đặt dirtrong configredis-cli, một khi bạn khởi động lại dịch vụ redis, điều này cũng sẽ bị xóa và lỗi tương tự sẽ xuất hiện lại. Giá trị mặc định của dirin redis.conflà ./và nếu bạn bắt đầu làm lại với tư cách người dùng root, thì đó ./là /quyền ghi không được cấp và do đó xảy ra lỗi.

Cách tốt nhất là đặt dirtham số trong tệp redis.conf và đặt quyền thích hợp cho thư mục đó. Hầu hết các bản phân phối debian sẽ có nó trong/etc/redis/redis.conf

Ngày nay, các vấn đề truy cập ghi Redis cung cấp thông báo lỗi này cho máy khách xuất hiện lại trong các redisthùng chứa docker chính thức .

Redis từ hình ảnh chính thứcredis cố gắng ghi tệp .rdb vào /datathư mục container , điều này khá đáng tiếc, vì nó là một thư mục thuộc sở hữu gốc và nó cũng là một vị trí không liên tục (dữ liệu được ghi ở đó sẽ biến mất nếu container / pod của bạn tai nạn).

Vì vậy, sau một giờ không hoạt động, nếu bạn đã chạy rediscontainer của mình với tư cách là người dùng không phải root (ví dụ như docker run -u 1007mặc định docker run -u 0), bạn sẽ nhận được thông báo lỗi chi tiết độc đáo trong nhật ký máy chủ của mình (xem 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

Vì vậy, những gì bạn cần làm là ánh xạ /datathư mục chứa tới một vị trí bên ngoài (nơi người dùng không phải root, ở đây: 1007, có quyền truy cập ghi, chẳng hạn như /tmptrên máy chủ), ví dụ:

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

Vì vậy, đó là một cấu hình sai của hình ảnh docker chính thức (nên viết là /tmpkhông /data) tạo ra "quả bom hẹn giờ" này mà bạn rất có thể sẽ chỉ gặp trong sản xuất ... qua đêm vào một số ngày nghỉ cuối tuần đặc biệt yên tĩnh: /

cho tôi

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

và tôi tải lại máy mac của mình, nó hoạt động

Tôi gặp vấn đề này khi làm việc trên máy chủ có dung lượng đĩa AFS vì mã thông báo xác thực của tôi đã hết hạn, điều này mang lại Permission Deniedphản hồi khi máy chủ redis cố lưu. Tôi đã giải quyết điều này bằng cách làm mới mã thông báo của mình:

kinit USERNAME_HERE -l 30d && aklog

Trong trường hợp bạn đang sử dụng docker / docker -compose và muốn ngăn redis ghi vào tập tin, bạn có thể tạo cấu hình redis và gắn vào một container

docker.compose.override.yml

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

Bạn có thể tải về cấu hình mặc định từ đây

trong tệp redis.conf, đảm bảo bạn nhận xét 3 dòng này

save 900 1
save 300 10
save 60 10000

myou có thể xem thêm giải pháp để xóa dữ liệu liên tục tại đây

Trong trường hợp của tôi, nó đã xảy ra bởi vì tôi chỉ cần cài đặt redisbằng cách nhanh chóng. Vì vậy, redis không chạy như root. Tôi đã có thể giải quyết vấn đề này bằng cách làm theo các hướng dẫn trong Installing Redis more properlyphần Hướng dẫn bắt đầu nhanh của họ . Sau khi làm như vậy, vấn đề đã được giải quyết và redishiện đang chạy như root. Kiểm tra nó ra.

Sau khi đập đầu tôi qua rất nhiều câu hỏi SO cuối cùng - đối với tôi câu trả lời của @Axel Advento đã có hiệu quả nhưng với vài bước bổ sung - tôi vẫn phải đối mặt với các vấn đề về quyền.
Tôi đã phải chuyển người dùng sang redis, tạo một thư mục mới trong thư mục chính của nó và sau đó đặt nó làm thư mục của redis.

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

Trong trường hợp của tôi, nó có liên quan đến không gian đĩa trống. (bạn có thể kiểm tra nó bằng df -hlệnh bash) khi tôi giải phóng không gian thì lỗi này đã biến mất.

Nếu bạn đang chạy Redis cục bộ trên máy Windows, hãy thử "chạy với tư cách quản trị viên" và xem nó có hoạt động không. Với tôi, vấn đề là Redis nằm trong thư mục "Tệp chương trình", điều này hạn chế quyền theo mặc định. Như là nó phải như thế.

Tuy nhiên, không tự động chạy Redis với tư cách quản trị viên Bạn không muốn cấp cho nó nhiều quyền hơn mà nó được cho là có. Bạn muốn giải quyết điều này bằng cuốn sách.

Vì vậy, chúng tôi đã có thể nhanh chóng xác định sự cố bằng cách chạy nó với tư cách quản trị viên, nhưng đây không phải là cách chữa. Một tình huống có thể xảy ra là bạn đã đặt Redis vào một thư mục không có quyền ghi và do đó, tệp DB được lưu trữ ở cùng vị trí đó.

Bạn có thể giải quyết điều này bằng cách mở redis.windows.confvà tìm kiếm cấu hình sau:

    # 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 ./

Thay đổi dir ./đường dẫn mà bạn có quyền đọc / ghi thông thường cho

Bạn cũng có thể chuyển toàn bộ thư mục Redis sang thư mục mà bạn biết có quyền.

Đối với tôi, đó chỉ là vấn đề về quyền trên thư mục dữ liệu redis liên tục. Tôi đã cho nó một:

chmod 777 -Rf data/

Và nó hoạt động! Có thể là sớm để nói rằng nó giải quyết vấn đề. Bởi vì tôi cũng nghi ngờ rằng redis không thực thi với quyền root nên tôi cần kiểm tra dockerFile của mình để tìm hiểu thêm.

Kiểm tra nhật ký Redis của bạn trước khi thực hiện bất kỳ hành động. Một số giải pháp trong chuỗi này có thể xóa dữ liệu Redis của bạn, vì vậy hãy cẩn thận với những gì bạn đang làm.

Trong trường hợp của tôi, máy đã hết RAM . Điều này cũng có thể xảy ra khi không còn dung lượng đĩa trống trên máy chủ.

Xin lưu ý rằng lỗi này xuất hiện khi máy chủ của bạn đang bị tấn công. Chỉ thấy rằng redis không ghi vào '/etc/cron.d/web' trong đó sau khi sửa quyền, tệp mới bao gồm thuật toán khai thác với một số tùy chọn ẩn đã được thêm vào.

# 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

Như @Chris đã chỉ ra, vấn đề có thể là bộ nhớ thấp. Chúng tôi bắt đầu trải nghiệm nó khi phân bổ quá nhiều RAM cho MySQL (innodb_buffer_pool_size ).

Để đảm bảo có đủ RAM cho Redis và các dịch vụ khác, chúng tôi đã giảm innodb_buffer_pool_sizetrên MySQL.

Trong trường hợp của tôi, lý do là không gian trống trong đĩa rất thấp (chỉ 35 Mb). Tôi đã làm như sau -

1. Đã dừng tất cả các thủ tục liên quan đến Redis
2. Xóa một số tệp trong đĩa để có đủ không gian trống

3. Xóa tệp kết xuất lại (nếu không cần dữ liệu hiện tại)

   sudo rm /var/lib/redis/*

4. Xóa tất cả các khóa của tất cả các cơ sở dữ liệu hiện có

   sudo redis-cli flushall

5. khởi động lại tất cả các nhiệm vụ cần tây và kiểm tra các bản ghi tương ứng cho bất kỳ vấn đề

bạn phải chmod và chown thư mục mới

chown -R redis và chmod ...