Upgrade Pika to 3.5.x: Key New Features, Migration Guide & Rollback Tips

1. New Version Overview

Before detailing the upgrade steps, a brief summary of the new features in version 3.5 is provided; see the reference documents at the end for more details.

Pika New Features

Rsync removal and new full sync solution : Pika 3.5 replaces the Rsync tool with a self‑developed full‑sync mechanism that supports breakpoint resume and dynamic speed throttling, greatly improving reliability.

Enhanced Redis command compatibility : Additional commands such as UNLINK, INFO COMMANDSTATS, HELLO, SETNAME, BLPOP, BRPOP are now supported, making migration and mixed usage smoother.

RocksDB upgrade with tiered compression : Upgraded to RocksDB 8.7.3 and introduced tiered compression, optimizing disk space utilization and data access efficiency.

BlobDB and Codis cluster mode support : Introduces BlobDB for KV‑layer separation and integrates Codis cluster mode with intelligent slot migration and management.

Containerization and cross‑platform support : The pika‑operator enables quick deployment on Kubernetes and adds support for macOS, CentOS, Ubuntu, and other platforms.

Observability and automation tools : Added pika_exporter with metrics for network I/O, command latency, fragmentation analysis, etc.

Performance and reliability improvements : Merged flush and compaction threads, optimized replication, and refined RocksDB compression and cache management.

Redis transaction support : Guarantees atomic execution of command sequences, enhancing data operation safety.

ACL and fast/slow command separation : Introduces ACL for multi‑tenant security and separates fast and slow commands to improve overall performance.

Dynamic configuration and rate limiting : Allows runtime adjustment of full‑sync and disk I/O throttling parameters for stable operation in complex environments.

Cache layer : Adds a hot/cold data separation cache to improve read performance.

2. Upgrade Procedure

Upgrade is performed by in‑place replacement of the binary executable. Because in‑place rollback is not possible, a rollback plan must be prepared before proceeding.

Upgrade Steps

Backup configuration and service files <code>cp /path/pika.conf /path/pika6379.conf.bak cp /etc/systemd/system/pika6379.service /etc/systemd/system/pika6379.service.bak</code>

Stop Pika service <code>redis-cli -p 6379 -a PASSWORD shutdown # or systemctl stop pika6379</code>

Detach replica from master <code>redis-cli -h 10.xxx -p 6379 -a PASSWORD slaveof no one</code>

Update configuration and service files Adjust thread numbers, cache size, sync threads, etc., according to CPU and memory. Example parameters for version 3.5 include: <code># thread-num : 1 # cputhread-pool-size : 8 # sync-thread-num : 6 # max-background-flushes : 1 # max-background-compactions : 1 # throttle-bytes-per-second : 45200000 # max-rsync-parallel-num : 1 # cache-num : 16 # cache-model : 1 # cache-type : string, set, zset, list, hash, bit # cache-maxmemory : 2147483648 # cache-maxmemory-policy : 1 # rate-limiter-bandwidth : 80200000 # cache-lfu-decay-time : 1 # block-cache : 524288000</code>

Start Pika service <code>/path/pika353/bin/pika -c /path/pika6379.conf # or systemctl start pika6379</code>

Optional data synchronization Use binlog_sender to apply incremental binlogs after the upgrade.

3. Rollback Strategies

Because major versions cannot be rolled back in‑place, two methods are offered.

Option 1 – Replica‑based rollback (preserve increments)

Before upgrading, add an old‑version replica and let it catch up. After the master upgrade, use binlog_sender to sync new binlogs to the old replica, then switch traffic to the old instance.

Option 2 – Full backup rollback (discard increments)

Take a full backup with BGSAVE before upgrading. If rollback is needed, restore the backup tarball and restart the old instance.

<code># BGSAVE
redis-cli -p 6379 -a PASSWORD BGSAVE
# pack backup
cd /path/pika/
cp -f pika6379.conf dump
cd /path/pika/dump
tar -cvf pika6379-20240820.tar pika6379-20240820 pika6379.conf
mv -xvf pika6379-20240820.tar /path/
# restore
tar -xvf pika6379-20240820.tar
mv pika6379-20240820 db
# start instance
/usr/local/pika32/bin/pika -c /path/pika6379.conf
# or
systemctl start pika6379</code>

4. Binlog_sender Overview

binlog_sender is bundled with Pika to replay binary logs to another Pika/Redis instance. It does not provide continuous synchronization, so scripts are needed for periodic execution.

Usage

<code>Usage:
    Binlog_sender reads from pika's binlog and send to pika/redis server
    -h    -- displays help
    -n    -- input binlog path
    -i    -- ip of the pika server
    -p    -- port of the pika server
    -f    -- files to send, default = 0
    -o    -- offset that the first file starts sending
    -s    -- start time (default '2001-00-00 00:59:01')
    -e    -- end time (default '2100-01-30 24:00:01')
    -a    -- password of the pika server
</code>

Sample Script

<code>#!/bin/bash
# parse arguments
while getopts ":n:i:p:a:t:f:" opt; do
  case ${opt} in
    n) BINLOG_PATH=$OPTARG ;;
    i) REMOTE_IP=$OPTARG ;;
    p) REMOTE_PORT=$OPTARG ;;
    a) PASSWORD=$OPTARG ;;
    t) INTERVAL=$OPTARG ;;
    f) START_BINLOG_NUM=$OPTARG ;;
    \?) echo "Usage: cmd -n binlog_path -i ip -p port -a password -t interval -f start_binlog_num"
        exit 1 ;;
  esac
done

INTERVAL=${INTERVAL:-300}
LAST_BINLOG_NUM_FILE="/tmp/last_binlog_num.txt"

get_first_binlog_num() { ls "$BINLOG_PATH" | grep -oP '(?<=write2file)[0-9]+' | sort -n | head -1; }
get_latest_binlog_num() { ls "$BINLOG_PATH" | grep -oP '(?<=write2file)[0-9]+' | sort -n | tail -1; }
get_last_binlog_num() {
  if [ -n "$START_BINLOG_NUM" ]; then
    echo "$START_BINLOG_NUM"
  elif [ -f "$LAST_BINLOG_NUM_FILE" ]; then
    cat "$LAST_BINLOG_NUM_FILE"
  else
    get_first_binlog_num
  fi
}
save_last_binlog_num() { echo "$1" > "$LAST_BINLOG_NUM_FILE"; }

while true; do
  latest_binlog_num=$(get_latest_binlog_num)
  last_binlog_num=$(get_last_binlog_num)

  if [ "$latest_binlog_num" -ge "$last_binlog_num" ]; then
    echo "Importing from $last_binlog_num to $latest_binlog_num"
    /usr/local/pika35/tools/binlog_sender -n "$BINLOG_PATH" -i "$REMOTE_IP" -p "$REMOTE_PORT" -f "$last_binlog_num-$latest_binlog_num" -a "$PASSWORD"
    save_last_binlog_num "$latest_binlog_num"
    unset START_BINLOG_NUM
  else
    echo "No new binlog files, waiting..."
  fi
  sleep "$INTERVAL"
done
</code>

5. Conclusion

Pika 3.5.x is now available on the HULK cloud platform with both master‑slave and cluster deployments, offering various plans to suit different scenarios. The version brings significant feature additions and performance gains, and the provided upgrade and rollback guides help ensure a smooth migration.