neverchanje commented on a change in pull request #695:
URL: https://github.com/apache/incubator-pegasus/pull/695#discussion_r580773293



##########
File path: rfcs/2021-02-22-disk-migrater.md
##########
@@ -0,0 +1,64 @@
+# Disk-Migrater
+
+## Overall
+Disk-Migrater is for migrating data among different disk volumns at one node,  
which is different from 
[node-balancer](http://pegasus.apache.org/administration/rebalance) that is for 
migrating data among different nodes. 

Review comment:
       ```suggestion
   Disk-Migrater is for migrating data among different local disks within one 
node. This feature is different from node-rebalance that is for migrating data 
among different nodes. 
   ```
   

##########
File path: rfcs/2021-02-22-disk-migrater.md
##########
@@ -0,0 +1,64 @@
+# Disk-Migrater
+
+## Overall
+Disk-Migrater is for migrating data among different disk volumns at one node,  
which is different from 
[node-balancer](http://pegasus.apache.org/administration/rebalance) that is for 
migrating data among different nodes. 
+
+## Flow Process
+Disk-Migrater operates by sending `RPC_REPLICA_DISK_MIGRATE` rpc to target 
node and goes on to trigger the node to migrate the `replica` from one disk to 
another. The whole migration process as follow: 

Review comment:
       ```suggestion
   Disk-Migrater operates by sending `RPC_REPLICA_DISK_MIGRATE` rpc to the 
targeted node that triggers the node to migrate the specified `replica` from 
one disk to another. The whole migration process is as follow: 
   ```

##########
File path: rfcs/2021-02-22-disk-migrater.md
##########
@@ -0,0 +1,64 @@
+# Disk-Migrater
+
+## Overall
+Disk-Migrater is for migrating data among different disk volumns at one node,  
which is different from 
[node-balancer](http://pegasus.apache.org/administration/rebalance) that is for 
migrating data among different nodes. 
+
+## Flow Process
+Disk-Migrater operates by sending `RPC_REPLICA_DISK_MIGRATE` rpc to target 
node and goes on to trigger the node to migrate the `replica` from one disk to 
another. The whole migration process as follow: 
+
+```
++---------------+      +---------------+       +--------------+
+| client(shell) +------+ replicaServer +-------+  metaServer  |
++------+--------+      +-------+-------+       +-------+------+
+       |                       |                       |
+       +------migrateRPC-----> +-----IDLE              |
+       |                       |       | (validate rpc)|
+       |                       |     MOVING            |
+       |                       |       | (migrate data)|
+       |                       |     MOVED             |
+       |                       |       | (rename dir)  |
+       |                       |     CLOSED            |
+       |                       |       |               |
+       |                +----- +<----LEARN<------------+
+       |                |      |                       |
+       |                |      |                       |
+       |           LearnSuccess|                       |
+       |                |      |                       |
+       |                |      |                       |
+       |                +----->+                       |
+```
+
+* target node receive the migrate-rpc and start validate rpc arguments
+* if the rpc is valid, node start migrate `replica` which contain 
`checkpoint`, `.init-info`,`.app-info`
+* after data migrate successfuly, the origin `replica` will be closed and 
`replica-server` re-opens the new `replica`
+* if the new `repica`  data is inconsistent with other replica(new write 
operation when migrating), it will be trigger to `learn` to catch up with the 
latest data by `meta-server`
+* after the `learn` is completed, the `migration` is successful

Review comment:
       ```suggestion
   1. The targeted node receives the migrateRPC and starts validating the 
request arguments.
   2. If the RPC is valid, node starts migrating the specified `replica`.
   3. After replica migration finishes successfuly, the original `replica` will 
be closed and ReplicaServer re-opens the new `replica`.
   4. If the new replica's data is inconsistent with its primary, MetaServer 
will automatically start to trigger replica-learn to catch up with the latest 
data.
   5. After the learning process is completed, the entire disk-migration ends.
   ```
   

##########
File path: rfcs/2021-02-22-disk-migrater.md
##########
@@ -0,0 +1,64 @@
+# Disk-Migrater
+
+## Overall

Review comment:
       ```suggestion
   ## Design Goals
   ```

##########
File path: rfcs/2021-02-22-disk-migrater.md
##########
@@ -0,0 +1,64 @@
+# Disk-Migrater
+
+## Overall
+Disk-Migrater is for migrating data among different disk volumns at one node,  
which is different from 
[node-balancer](http://pegasus.apache.org/administration/rebalance) that is for 
migrating data among different nodes. 
+
+## Flow Process
+Disk-Migrater operates by sending `RPC_REPLICA_DISK_MIGRATE` rpc to target 
node and goes on to trigger the node to migrate the `replica` from one disk to 
another. The whole migration process as follow: 
+
+```
++---------------+      +---------------+       +--------------+
+| client(shell) +------+ replicaServer +-------+  metaServer  |

Review comment:
       ```suggestion
   | client(shell) +------+ ReplicaServer +-------+  MetaServer  |
   ```




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to