GitLab关联Redis启动失败（ASSERTION FAILED OBJECT CONTEXT）

Hey there, let's break down what's happening here. From your logs, the core issue is that Redis is crashing with a segmentation fault when loading the RDB persistence file specified in GitLab's configuration. When you start Redis without a config (so it doesn't load that specific RDB), it runs fine—so the problem is tied to either the RDB file itself or the Redis config GitLab is using.

Root Cause Analysis #

Looking at the stack trace, the crash happens in rdbLoad → dbAdd, which means Redis is failing to add data from the RDB file to its database. The assertion failure (retval == DICT_OK at db.c:161) points to a corrupted RDB file being the most likely culprit.

Troubleshooting & Fix Steps #

1. First, Back Up Your Data #

Before making any changes, back up the Redis data directory to avoid losing any existing data:

cp -r /var/opt/gitlab/redis/ /var/opt/gitlab/redis_backup_$(date +%Y%m%d)

2. Check RDB File Integrity #

Use Redis's built-in tool to verify if the RDB file is corrupted:

/opt/gitlab/embedded/bin/redis-check-rdb /var/opt/gitlab/redis/dump.rdb

If this tool reports corruption, that's your smoking gun.

3. Skip the Corrupted RDB to Test #

If the RDB is corrupted, rename it so Redis starts fresh without loading it:

mv /var/opt/gitlab/redis/dump.rdb /var/opt/gitlab/redis/dump.rdb.broken

Now try starting Redis with GitLab's config again:

/opt/gitlab/embedded/bin/redis-server /var/opt/gitlab/redis/redis.conf

If it starts successfully, you've confirmed the RDB was the issue. Note that this will mean losing the old Redis data—if you need to recover it, you can try using redis-check-rdb's repair functionality, or restore from a recent GitLab backup.

4. Validate Redis Configuration #

If skipping the RDB still causes a crash, check the config file for issues:

• Verify the dir setting points to a valid directory with correct permissions (owned by gitlab-redis user):

  grep "dir" /var/opt/gitlab/redis/redis.conf
  ls -ld /var/opt/gitlab/redis/
  

• Ensure dbfilename matches the actual file name in the directory, and the file has proper read/write permissions.

Also, while not the direct cause of this crash, fix the two warnings in your logs to prevent future issues:

# Fix overcommit_memory temporarily
sysctl vm.overcommit_memory=1
# Make it permanent by adding to /etc/sysctl.conf
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

# Disable Transparent Huge Pages temporarily
echo never > /sys/kernel/mm/transparent_hugepage/enabled
# Make it permanent (add to /etc/rc.local for traditional init systems)
echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.local
chmod +x /etc/rc.local

5. Restart GitLab Services #

Once Redis starts correctly with the config, restart the entire GitLab stack:

gitlab-ctl restart

Preventive Measures #

• Regularly check RDB file integrity using redis-check-rdb
• Ensure your server has enough free memory to avoid RDB corruption during persistence
• Fix the system-level warnings mentioned in the logs to eliminate potential instability points

内容的提问来源于stack exchange，提问作者David Rojo