From b2ff324882d272177e8a1df9e55ec2513e777f85 Mon Sep 17 00:00:00 2001
From: ZhaolongLi <0x4f4f4f4f@gmail.com>
Date: Mon, 13 Sep 2021 12:39:13 +0800
Subject: [PATCH] fix wrong file name (#291)

---
 doc/project3-MultiRaftKV.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/project3-MultiRaftKV.md b/doc/project3-MultiRaftKV.md
index 0f1624e1..d06bfd68 100644
--- a/doc/project3-MultiRaftKV.md
+++ b/doc/project3-MultiRaftKV.md
@@ -108,7 +108,7 @@ So your task is to implement the process of handling split admin command, just l
 
 As we have instructed above, all data in our kv store is split into several regions, and every region contains multiple replicas. A problem emerged: where should we place every replica? and how can we find the best place for a replica? Who sends former AddPeer and RemovePeer commands? The Scheduler takes on this responsibility.
 
-To make informed decisions, the Scheduler should have some information about the whole cluster. It should know where every region is. It should know how many keys they have. It should know how big they are…  To get related information, the Scheduler requires that every region should send a heartbeat request to the Scheduler periodically. You can find the heartbeat request structure `RegionHeartbeatRequest` in `/proto/proto/pdpb.proto`. After receiving a heartbeat, the scheduler will update local region information.
+To make informed decisions, the Scheduler should have some information about the whole cluster. It should know where every region is. It should know how many keys they have. It should know how big they are…  To get related information, the Scheduler requires that every region should send a heartbeat request to the Scheduler periodically. You can find the heartbeat request structure `RegionHeartbeatRequest` in `/proto/proto/schedulerpb.proto`. After receiving a heartbeat, the scheduler will update local region information.
 
 Meanwhile, the Scheduler checks region information periodically to find whether there is an imbalance in our TinyKV cluster. For example, if any store contains too many regions, regions should be moved to other stores from it. These commands will be picked up as the response for corresponding regions’ heartbeat requests.