Uncategorized

Write-Behind Caching Strategy

In write-behind caching (also known as write-back caching), the application first writes data to the cache. After a set period of delay, the cache writes this information to the database as well. Write-behind caches are best for write-heavy workloads and can perform well even with some failures and downtime.

First check the number of redis nodes using ps command

Now identify the Master and Slave nodes, slaves nodes needs to be shutdown first

Now we need to shutdown the slaves at port 7001, 7005 and 7006

You can double check the port using role command

If by mistake a master is closed instead of slave then it will be considered as a failback and slave will become the master hence slave has to closed before closing master

Below is output where the redis was started, it can be std.out or std.err

Now Shutdown the master similarly and you are done

• Used for Data storage in more than one instance
• Redis Cluster allows you to host multiple master shards
• Data is automatically sharded across multiple Redis Nodes
• Automatically splits data among multiple nodes
• Continues to operation when a subset of the nodes are experiencing failures
• Some degree of availability during partitions

Goals :

• High performance and linear scalability up to 1000 nodes
• An acceptable degree of writing safety
• Availability

How it works

• DataSharding is based on Key-Hash tags
• Each master node in a cluster handles a subset of the 16384 hash slots
• How is hash calculated? which decides the node in which the key will land ?
  • It takes the CRC16 of the key and it decides the bucket/node in which it is gonna be stored
  • Always the CRC16 of the key will be less than 16384 values
  • So suppose if there are 4 nodes then each node can handle 16384/4 nodes
• Every node in a redis cluster is responsible for a subset of the hash slots
• Redis Cluster only supports Database 0

Example :

We will be creating a cluster of 6 nodes, out of which 3 will be master nodes and 3 will be replica/slave nodes.

We will start by creating .conf file for our nodes

n1_redis.conf

port 7001
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

Similarly, we will create 5 more redis.conf file. n2_redis.conf file, n3_redis.conf file,n4_redis.conf file,n5_redis.conf file and n6_redis.conf file

We will move each conf file into a directory so that we can keep logs and other file for a single node into a directory

Now we will naviagte to each directory and start the redis-server with that .conf file

redis-server n1_redis.conf &

Similarly start all the 6 clusters

Check if all the 6 clusters are running using ps command

ps -ef | grep -i 'redis'

Now enable replica for all the 6 nodes to form a failover cluster

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1

You have to enter Yes to accept the configuration

Method one to view the summary of the cluster

Method two to view the summary of the cluster

Checking the slots of the Cluster

Connect to the cluster using below command

redis-cli -c -p 7001

Example of how keys are sharded between master nodes

In above example 7002, 7003 and 7004 are master

When you execute role command on master, below is the output :

1 ) “master” – Indicates that the cli is connected to is a master

2) (integer) 21589 – Offset of master

3) 1) – Indicates that only 1 replica / slave exist for the master

3) 1) 1) “127.0.0.1” – Hostname of slave

2) “6380” – Port Number of slave

3) “21589” – Offset of slave (Acknowledgement of replication offset data received)

When you execute role command on slave, below is the output :

1. “slave” – Indicates that the cli is connected to slave
2. “Localhost” hostname
3. 6379 – port number
4. “connected” – All good
   • disconnected – Not connected
   • sync – sync is in progress
   • connecting – connection establishment in progress
5. 22696 – Offset of slave (Acknowledgement of replication offset data received)

Important redis info commands

• INFO keyspace
• INFO stats
• INFO errorstats
• INFO replication
• INFO cpu
• INFO modules
• INFO cluster

• sync_partial_err
• rejected_connections
• total_read_processed
• total_write_processed

• Get into TMUX
  • Command “tmux”
• Split screen Verticall
  • Command “Ctrl + B”
  • Release pressed keys in step 1
  • Press Shift + 5
• Split screen Horizontally

Commands to split the screen

Reference :

Tmux-Cheatsheat

Master / Slave Replication

First Server instance

 redis-server --port 6379 --dbfilename db1.rdb

Second Server instance

redis-server --port 6380 --dbfilename db2.rdb

Connect to 1st Server instance

Connect to 2nd Server instance

Now let us convert the second server into a replica

2nd Server CLI – Hit command replicaof

1st Server CLI again checked the replication id to check if it matches the server

Below changes are observed in the console of 2nd Redis Server

Checking if the 2nd Server (replica) CLI has the same keys as Master

Replication Example (TMUX used just to display side by side)

• Write on replica fails since it is read only

How to stop replication ?

#Connect to the replication server via CLI
#Enter below command
replicaof no one
#Connect to the master server via CLI
#Check the number of slaves via command "INFO REPLICAION"

How to check if replication is happening or not ?

• The replica offset should increase for the slave everytime data is inserted into the master

Example to print keys and values in shell script :

#!/bin/bash
redis-cli --scan > all.keys
while read -r key
do
  value=$(redis-cli get "$key")
  echo $key '|' $value
done < all.keys

Directly get all the values from keys using redis cli