Can I configure Redis slave to stop saving dumps? I have omitted all save instructions in config file but slave is still doing dumps.
So I assume you have checked in the configuration file of the slave that RDB is deactivated (all save lines commented out), and the slave has been restarted after the configuration file has been changed (so this configuration is active).
At this point the background dump operation of the slave is deactivated, but it does not prevent the slave to write a dump file. Actually, the slave has to write a dump file at startup time: this is how it retrieves the data from the master in bulk mode.
When the slave starts, it sends a SYNC request to the master:
The master starts accumulating Redis commands.
The master performs a background dump
The master sends the dump file to the slave in bulk mode
The slave reads the dump file from the master and write it to the disk
When it is complete, the slave loads the dump file from the disk
The slave starts processing Redis commands accumulated by the master
Eventually, the slave will catch up
The slave is in sync with the master
That's why you can find dump files on slave side even if RDB is deactivated for the slaves.
A good reading is http://redis.io/topics/persistence
Redis has 2 kinds of persistence, you should disable AOF too:
Append-only file
Snapshotting is not very durable. If your computer running Redis
stops, your power line fails, or you accidentally kill -9 your
instance, the latest data written on Redis will get lost. While this
may not be a big deal for some applications, there are use cases for
full durability, and in these cases Redis was not a viable option. The
append-only file is an alternative, fully-durable strategy for Redis.
It became available in version 1.1.
You can turn on the AOF in your configuration file:
appendonly yes
From now on, every time Redis receives a command that changes the
dataset (e.g. SET) it will append it to the AOF. When you restart
Redis it will re-play the AOF to rebuild the state.
Related
I have configured two slaves and one master using sentinel.
I have turned off persistence on all the servers. Now the sync happens between master and slave using BGSAVE command.
So shall i assume that though i have persistence off redis is still persisting since it created rdb file for syncing data?
I guess you just have to use replication diskless to avoid Redis using BGSAVE. In fact diskless replication use socket instead of the file to send data on their slaves
https://deepsource.io/blog/redis-diskless-replication/
regard,
I am wanting to configure in-memory REDIS Master with a Slave providing the persistence to AOF and RDB.
In the event of a crash or reboot, is there an easy way to reload the in-memory master? To load from the AOF provided by the Slave instance?
Thanks
I have a redis setup with sentinels and multiple slaves, each slave as well as the master writes persistently to a snapshot file.
When I restart the system, every slave has more keys in their instance than the master has (but less keys than are present in their snapshot file), and I do not understand why?
1) My question, does a slave ever read the snapshot file at startup or it only synch with the master?
2) I never copy my snapshot files, does this lead to overwrite problems?
3) If I have keys with EXPIRATION, are those removed form the snapshot file at the corresponding time?
1) My question, does a slave ever read the snapshot file at startup or it only synch with the master?
When a slave restarts, it loads snapshot(RDB) file from disk if there's no AOF file.
2) I never copy my snapshot files, does this lead to overwrite problems?
It has nothing to do with copying.
3) If I have keys with EXPIRATION, are those removed form the snapshot file at the corresponding time?
When Redis loads the RDB file, if a key has expiration, Redis will add the key value to dict and set expiration for that key. No matter whether the key has already expired (the key will be removed later).
When I restart the system, every slave has more keys in their instance than the master has
The slaves might NOT full sync with the master before they are shutdown, and some keys have been deleted from the master. After re-syncing with the master, those keys will be deleted from slaves.
How to disable Save for some DBs and allow for the others in the Redis
You cannot. An RDB snapshot is a single file that contains the data of all dbs.
You can send a FLUSHDB on the dbs you do not want to restore after the RDB is loaded.
If you'll use a dedicated Redis process for each db you could configure each one differently with a dedicated redis.conf file, and a SAVE and BGSAVE commands will only create a snapshot of the Redis process it was issued on.
Starting with Redis 2.8,redis add a function named "Partial resynchronization".I read this official document,but i don't understand.who can help me?
It is about master-slave replication.
The normal behavior of a Redis slave (slave of command, or configuration) is to connect to the master, ask the master to accumulate master-slave traffic, request a complete dump on filesystem to the master, download this dump on the slave, load the dump, and finally play the accumulated traffic until the slave catches up with the master.
This mechanism is quite robust but not very efficient to cover transient connection drops between the slave and the master. If the master-slave link is down for a couple of seconds, the slave will request a full resynchronization (involving a dump, etc ...), even if only a few commands have been missed.
Starting with 2.8, Redis includes a partial replication mechanism so a slave can reconnect to the master, and if some conditions are met (like a transient connection drop), asks the master to resynchronize without having to dump the whole memory instance.
In order to support this feature, the master has to buffer and keep a backlog of commands, so they can be served to the slaves at any time if needed. If the slave is too late behind the master, the backlog may not contain anymore the required data. In that case, a normal full synchronization is done, as in previous versions.