v1.1.0

redis-GunYu v1.1.0

The new bidirectional synchronization capability in redis-GunYu, for running A -> B and B -> A sync links between two Redis deployments.

Highlights

• Added bidirectional synchronization for both Redis standalone and Redis cluster
• Supports both AOF incremental sync and RDB full-sync replay paths
• Each replay unit is committed with a real MULTI/EXEC transaction, including business commands, loop-suppression markers, and recovery metadata
• Supports recovery after syncer restart, Redis failover, and target cluster topology changes
• Added unified output.replay.mode configuration for replay execution semantics
• Legacy enableAofPipeline is still accepted for backward-compatible loading, but new configurations should migrate to output.replay.mode

Recommended Usage

• Enable bisyncEnabled: true on both sync directions
• Use mode: sync as the default production choice for consistency-sensitive workloads
• Validate pipeline separately before production rollout if you plan to use it
• Start with a limited business prefix, slot range, or controlled traffic scope during canary rollout

Important Notes

• Bisync does not resolve same-key conflicts across both sides
• Some Redis module commands and commands whose keys cannot be proven are not recommended for production bisync traffic yet
• Do not read, write, migrate, or delete GunYu control-plane keys such as redis-gunyu-bisync:*, redis-gunyu-checkpoint*, or /redis-gunyu*

Upgrade Notes

• bisyncEnabled is the only explicit switch for bisync
• replayTransaction is still recommended, but it is not the bisync switch
• New configurations should use output.replay.mode instead of the legacy enableAofPipeline

Rollout Recommendation

• Validate against the production Redis version before rollout
• Monitor syncer status, bisync metrics, Redis resource usage, and data comparison results during canary
• Keep a rollback plan ready to disable bisyncEnabled or stop the reverse link quickly if needed

Full release documentation:

• release
• bisync