Redis Data Persistence (Veri Kalıcılığı)

Giriş 

4 çeşit persistence özelliği sağlar. Açıklaması şöyle

So Redis provides a different range of persistence options:

- RDB (Redis Database): The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.

- AOF (Append Only File): The AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log in the background when it gets too big.

- No persistence: If you wish, you can disable persistence completely, if you want your data to just exist as long as the server is running.

- RDB + AOF: It is possible to combine both AOF and RDB in the same instance. 

Bu 4 taneden sadece 2 tanesi diske bir şey yazar. Bunlar

1. Snapshot (Anlık Durum)

2. Append Only File (AOF)

Açıklaması şöyle

Redis supports two modes of file system persistence — append-only file (AOF) and snapshotting (RDB):

1. Snapshot Persistence

Açıklaması şöyle. Anlık Durum veri kalıcılığı ile belli aralıklarda veri kaydedilir. İki kayıt zamanı arasındaki veri kaybolabilir.

It saves data in one of the following cases:

- automatically from time to time

- when redis is shutting down

Bazı avantajlar şöyle. Eğer dosya arşivlenmişse geçmişteki bir ana gidebilmek mümkün.

RDB advantages :

- RDB is a very compact single-file point-in-time representation of your Redis data. RDB files are perfect for backups. For instance, you may want to archive your RDB files every hour for the latest 24 hours and to save an RDB snapshot every day for 30 days. This allows you to easily restore different versions of the data set in case of disasters.

- RDB is very good for disaster recovery, being a single compact file that can be transferred to far data centers.

- RDB allows faster restarts with big datasets compared to AOF

Dosya ismi şöyle

By default Redis saves snapshots of the dataset on disk, in a binary file called dump.rdb. You can configure Redis to have it save the dataset every N seconds if there are at least M changes in the dataset, or you can manually call the SAVE or BGSAVE commands.

Kaydetme sıklığı şöyle. Yani sabit bir periyodda çalışmıyor

So Redis stores snapshots of your data to disk in a dump.rdb file in the following conditions:

- Every minute if 1000 keys were changed

- Every 5 minutes if 10 keys were changed

- Every 15 minutes if 1 key was changed

So if you’re doing heavy work and changing lots of keys, then a snapshot per minute will be generated for you, in case your changes are not that much then a snapshot every 5 minutes, if it’s really not that much then every 15 minutes a snapshot will be taken.

2. Append Only File Persistence

Açıklaması şöyle

- Append-only file is similar to write-ahead logs employed by SQL databases that record each mutating operation to a file that can be played back at database start to recover the data.

Bu özelliği etkinleştirmek için konfigürasyon dosyasında şöyle yaparız

appendonly yes

fsync seçenekeri şöyle

As we explained in AOF section we have the following options for durability levels

appendfsync always: fsync every time new commands are appended to the AOF. Very very slow, very safe. Note that the commands are appended to the AOF after a batch of commands from multiple clients or a pipeline are executed, so it means a single write and a single fsync (before sending the replies).

appendfsync everysec: fsync every second. Fast enough (in 2.4 likely to be as fast as snapshotting), and you can lose 1 second of data if there is a disaster.

appendfsync no: Never fsync, just put your data in the hands of the Operating System. The faster and less safe method. Normally Linux will flush data every 30 seconds with this configuration, but it's up to the kernel exact tuning.

appendfsync everysec Seçilirse

1 saniye yerine 2 saniyelik veri kaybedersiniz diyen bir yazı da var. Hangisi doğru bilmiyorum

Bu İkisi Birlikte Kullanılır

Açıklaması şöyle. Aslında ikisi birlikte kullanılınca ne olacağına dair farkı açıklamalar var. Bir açıklama sadece AOF kullanılır diyor, bir diğeri de Snapshot + AOF birlikte kullanılır diyor.

At specified intervals, Redis snapshots all in-memory data. By default, it is done every 60 seconds (customizable). Redis copies the current in-memory data using OS.fork and then stores data to the disk. 

In case of an abnormal shutdown, Redis recovers its status from the most recent saving. If the last snapshot was made a long time ago, all the data received after the snapshot will be lost.

The transaction journal is used to store all the information arriving at the database. Every operation is logged in the on-disk journal. When Redis is started, it recovers its status from the snapshot and then adds the remaining operations from the journal.

Troubleshooting

Açıklaması şöyle

If a journal file is damaged in Redis:

redis-check-aof --fix

Diğer Alternatifler

Redis'in veri kalıcılığı yerine diğer genel çözümler şöyle

Except for kvrocks, the open-source community has some similar disk key-value systems and can divide into three categories:

1. Implement the Redis protocol and replication based on disk key-value engine, like LevelDB, RocksDB, etc…

2. Swap Redis cold keys into the disk storage like Redis on Flash, or the Redis VM in the old version but deprecated now

3. Implement the Redis proxy based on the distributed KV(e.g. TiKV). Data integrity and durability are in the hand of Redis

etcd vs Redis

etcd vs Redis yazısında, Redis'in tam anlamıyla konfigürasyon verisini saklamak için uygun olmadığına dikkat çekiliyor. Burada sanırım en önemli fark, slave düğümlerin master ile sync işlemi başlatmasından kaynaklanıyor. Burada da bir soru var.

etcd vs. Redis

Like etcd, Redis is an open source tool, but their basic functionalities are different.

Redis is an in-memory data store and can function as a database, cache, or message broker. Redis supports a wider variety of data types and structures than etcd and has much faster read/write performance.

But etcd has superior fault tolerance, stronger failover and continuous data availability capabilities, and, most importantly, etcd persists all stored data to disk, essentially sacrificing speed for greater reliability and guaranteed consistency. For these reasons, Redis is better suited for serving as a distributed memory caching system than for storing and distributed system configuration information.