After the previous MySQL container rebuilding, the change master to command binding association needs to be re-run, and 8.0 needs to take effect from the command line.
Redis first thought of using the official, but did not expect to go into the basic shell commands can not be used, so abandoned. This time, because the official does not provide the basic configuration file, unzip redis-5.0.5.tar.gz to copy the main configuration redis.conf, sentinel.conf to the current directory, such as: / root/tmp/dk/redis.
1. Making Configuration Files
# Master server redis.conf: - # requirepass foobared + requirepass 123456 - dir. / persistent data directory + dir /data - Appndonly no # Open AOF + appendonly yes - Bid 127.0.0.1# Allows IP access to the extranet + bind 0.0.0.0 // Slave Server: Master + Additional redis.conf: // remote_host: your own intranet and extranet addresses - # replicaof <masterip> <masterport> + replicaof remote_host 6379 - # masterauth <master-password> + masterauth 123456
2. Start Container
# Create Container Running :~/tmp/dk/redis# docker run --name rm \ -p 6379:6379 --restart=always -v \ /root/tmp/dk/redis/data:/data -v \ /root/tmp/dk/redis/redis.conf:/etc/redis/redis.conf \ -d cffycls/redis5:1.6 redis-server /etc/redis/redis.conf :~/tmp/dk/redis# docker run --name rs \ -p 6381:6379 --restart=always -v \ /root/tmp/dk/redis_slave/data:/data -v \ /root/tmp/dk/redis_slave/redis.conf:/etc/redis/redis.conf \ -d cffycls/redis5:1.6 redis-server /etc/redis/redis.conf
Mirror image is compiled by redis 5.0.5. It is master-slave synchronization after direct boot, and does not need to be configured as MySQL (where the starting data is inconsistent: when modified to the current final configuration, the synchronization is intact when restarted). Direct synchronization was successful, and the info replication of the relationship was checked in master and slave.
3. Other circumstances
A. Baidu replica of
“The description of master-slave architecture is changed to master-replica, SLAVEOF provides the alias REPLICAOF, so SLAVEOF can still be used.”
B. Whether to guard the process
After many tests, it was found that redis would start normally when the container was restarted. Daemonize no should be kept at no, otherwise the error will be reported:
Error response from daemon: Container xx is restarting, wait until the container is running
It is known that the daemon process in the container is in conflict with docker itself. Keep the default daemonize no normal. Don’t modify the parameters first. Consider the difference between the daemonize process and the host installation.
Does the c.bind address need to be modified?
The password has been set, so protected-mode remains the default.
- Protect-mode yes
- Protect-mode no Open protected-mode protection mode, need to configure bind IP or set access password
Here is a lot of configuration reboot tests, master-slave: 127.0.0.1-127.0.0.0.1 can be accessed, but the single master-slave relationship has not been established; 0.0.0-127.0.0.1 is normal, anyway, the recommendation is 0.0.0-0.0.0.0.0.0.
Like mysql, you need to restart the load configuration using docker restart RMS restart mode. Sentinel deployment is similar, skipped.
This is based on the previous revision of the Dockerfile of redis, which was pushed to the official public cloud of cffycls/redis 5:1.6.