Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Data in the cluster module means both timeseries schemas and timeseries data since they are partitioned into multiple DataGroups and not stored globally, so coordinators may be necessary to find the right nodes that should store the corresponding data. As the partition table is the sole data structure that may help coordination, its owner, MetaMember, works as a coordinator in the cluster moduleCoordinator need the help of MetaMember. Fig.5 shows the whole procedure involving cluster data related operations.

...

  1. A client sends a request to the coordinator's ClientServer;
  2. ClientServer parses the request and lets Coordinator handle it;
  3. Coordinator routes the request with the help of metaMember;
  4. MetaMember Coordinator sends the request to the DataGroup(s) that should process it; the request may be split before sending to each DataGroup;
  5. The receivers process the request and return their responses to MetaMemberCoordinator;
  6. MetaMember Coordinator concludes the results and return it to the client;

...

  1. A client sends a request to the leader's ClientServer;
  2. ClientServer parses the request and lets MetaMember Coordinator handle it;
  3. MetaMember Coordinator routes the request with the help of its coordinatormetaMember;
  4. Finding out that the node should process the request, MetaMember forwards the request to its DataClusterServer;
  5. DataClusterServer finds the associated DataMember that should process it;
  6. DataMember creates a log for the request and appends it to its RaftLogManager;
  7. DataMember sends the log to other nodes in its DataGroup;
  8. After sending to enough replicas, DataMember commit the log to its RaftLogManager;
  9. RaftLogManager then applies the log to the underlying IoTDB;
  10. The result is returned to the client.

...