---
title: "Comment by Crownforge on \"System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens\" | Hashnode"
description: "How would you recover if the Redis fencing counter is lost but MySQL still has a high fence_token? Starting INCR from zero again would leave new holders unable"
url: "https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae0790ad9806620b2758b28"
---

[Discussion](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0)

Comment [System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0)

[Crownforge](https://hashnode.com/@thecrownforge)

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae0790ad9806620b2758b28)

How would you recover if the Redis fencing counter is lost but MySQL still has a high fence\_token? Starting INCR from zero again would leave new holders unable to write until the counter catches up. That seems worth a recovery test alongside the stale holder test

[Anish Ansari](https://hashnode.com/@anish78)

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae0790ad9806620b2758b28#reply-6ae07c7087f3dfa3c629747f)

Fair question. I'd reseed the Redis counter from MAX(fence\_token) in MySQL before any lock is handed out again, and a test that wipes the counter and checks the next holder can still write is definitely worth adding.