Manifest-based snapshots in distributed computing environments
Scalable architectures, systems, and services are provided herein for creating manifest-based snapshots in distributed computing environments. In some embodiments, responsive to receiving a request to create a snapshot of a data object, a master node identifies multiple slave nodes on which a data object is stored in the cloud-computing platform and creates a snapshot manifest representing the snapshot of the data object. The snapshot manifest comprises a file including a listing of multiple file names in the snapshot manifest and reference information for locating the multiple files in the distributed database system. The snapshot can be created without disrupting I/O operations, e.g., in an online mode by various region servers as directed by the master node. Additionally, a log roll approach to creating the snapshot is also disclosed in which log files are marked. The replaying of log entries can reduce the probability of causal consistency in the snapshot.
1. A computer-implemented method for operating a distributed computing platform, the platform including a master node and a plurality of slave nodes, each slave node implementing a region server associated with a data node, the method comprising:
responsive to a request for a snapshot of a data object in the platform, identifying, by the master node, one or more data nodes on which the data object is stored, wherein each identified data node stores a partition of the data object;
generating, by the master node, a request to each region server among the region servers associated with the identified one or more data nodes for a portion of the snapshot manifest corresponding to the partition of the data object stored on the data node associated with the region server; and
combining responses from the region servers that receive the requests to create the snapshot manifest representing the snapshot of the data object
wherein the platform is configured not to modify a respective partition of a data object stored on a data node except for merging or splitting the respective partition.
2. The method of claim 1 , wherein the snapshot of the data object contains names for the partitions of the data object and reference information for locating the partitions of the data object in the platform.
3. The method of claim 1 , further comprising:
creating an archived copy of the respective partition of the data object before merging or splitting the respective partition.
4. The method of claim 3 , further comprising:
updating reference information in the snapshot of the data object to point to a location where the archived copy of the respective partition is stored.
5. The method of claim 1 , wherein the snapshot manifest is created in an offline mode, and the method further comprises:
disabling access to a table; and
examining a namespace to determine which partitions of the data object form the table.
6. The method of claim 1 , wherein the snapshot manifest is created in an online mode, and the method further comprises:
causing the region servers associated with the identified one or more data nodes to flush data currently in memory into a table.
7. The method of claim 6 , wherein the platform continues to accept input/output operations from clients during creation of the snapshot manifest.
8. The method of claim 1 , further comprising:
backing up data in the platform by performing a MAPREDUCE job and based on the snapshot manifest, wherein the backing up step does not involve table manipulation commands.
9. The method of claim 1 , further comprising:
cloning a table based on the snapshot.
10. The method of claim 9 , wherein the cloning of the table comprises:
creating a copy of a table metadata; and
copying relevant partitions of the data object on each associated data node into a new directory on the associated data node.
11. The method of claim 10 , wherein a copy of a relevant partition of the data object comprises a link to the relevant partition but not actual data of the relevant partition.
12. The method of claim 1 , further comprising:
rolling back a table to a previous state based on the snapshot.
13. The method of claim 1 , further comprising:
detecting a causal inconsistency in the platform.
14. The method of claim 13 , wherein the causal inconsistency comprises data having been input into the platform but being unaccounted for in the snapshot.
15. The method of claim 13 , further comprising:
resolving the causal inconsistency by sending a request to a respective region server.
16. The method of claim 15 , wherein the request causes the respective region server to perform steps comprising:
adding an entry to a log for a memory flush; and
placing a marker in the log, wherein the marker indicates the creation of the snapshot.
17. The method of claim 16 , further comprising:
restoring a table based on the snapshot.
18. The method of claim 17 , wherein the restoring of the table comprises:
clearing the table; and
reenacting log entries or replaying the log.
19. The method of claim 1 , wherein the master node comprises an HBASE master node, the slave nodes comprise HBASE slave nodes, and the data object comprises a HADOOP table.
20. A computer-implemented method for operating a distributed computing platform, the platform including a master node and a plurality of slave nodes, each slave node implementing a region server associated with a data node, the method comprising:
responsive to a request for a snapshot of a data object in the platform, identifying, by the master node, one or more data nodes on which the data object is stored, wherein each identified data node stores a partition of the data object;
generating, by the master node, a request to each region server among the region servers associated with the identified one or more data nodes for a portion of the snapshot manifest corresponding to the partition of the data object stored on the data node associated with the region server;
combining responses from the region servers that receive the requests to create the snapshot manifest representing the snapshot of the data object; and
cloning a table based on the snapshot, wherein the cloning of the table comprises:
creating a copy of a table metadata; and
copying relevant partitions of the data object on each associated data node into a new directory on the associated data node;
wherein a copy of a relevant partition of the data object comprises a link to the relevant partition but not actual data of the relevant partition.
21. The method of claim 20 , wherein the snapshot of the data object contains names for the partitions of the data object and reference information for locating the partitions of the data object in the platform.
22. The method of claim 20 further comprising:
creating an archived copy of the respective partition of the data object before merging or splitting the respective partition.
23. The method of claim 22 , further comprising:
updating reference information in the snapshot of the data object to point to a location where the archived copy of the respective partition is stored.
24. The method of claim 20 , wherein the snapshot manifest is created in an offline mode, and the method further comprises:
disabling access to the table; and
examining a namespace to determine which partitions of the data object form the table.
25. The method of claim 20 , wherein the snapshot manifest is created in an online mode, and the method further comprises:
causing the region servers associated with the identified one or more data nodes to flush data currently in memory into the table.
26. The method of claim 25 , wherein the platform continues to accept input/output operations from clients during creation of the snapshot manifest.
27. The method of claim 20 , further comprising:
backing up data in the platform by performing a MAPREDUCE job and based on the snapshot manifest, wherein the backing up step does not involve table manipulation commands.
28. The method of claim 20 , further comprising:
rolling back the table to a previous state based on the snapshot.
29. The method of claim 20 , further comprising:
detecting a causal inconsistency in the platform.
30. The method of claim 29 , wherein the causal inconsistency comprises data having been input into the platform but being unaccounted for in the snapshot.
31. The method of claim 29 , further comprising:
resolving the causal inconsistency by sending a request to a respective region server.
32. The method of claim 31 , wherein the request causes the respective region server to perform steps comprising:
adding an entry to a log for a memory flush; and
placing a marker in the log, wherein the marker indicates the creation of the snapshot.
33. The method of claim 32 , further comprising:
restoring the table based on the snapshot.
34. The method of claim 33 , wherein the restoring of the table comprises:
clearing the table; and
reenacting log entries or replaying the log.
35. The method of claim 20 , wherein the master node comprises an HBASE master node, the slave nodes comprise HBASE slave nodes, and the data object comprises a HADOOP table.
36. A computer-implemented method for operating a distributed computing platform, the platform including a master node and a plurality of slave nodes, each slave node implementing a region server associated with a data node, the method comprising:
responsive to a request for a snapshot of a data object in the platform, identifying, by the master node, one or more data nodes on which the data object is stored, wherein each identified data node stores a partition of the data object;
generating, by the master node, a request to each region server among the region servers associated with the identified one or more data nodes for a portion of the snapshot manifest corresponding to the partition of the data object stored on the data node associated with the region server;
combining responses from the region servers that receive the requests to create the snapshot manifest representing the snapshot of the data object; and
detecting a causal inconsistency in the platform.
37. The method of claim 36 , wherein the snapshot of the data object contains names for the partitions of the data object and reference information for locating the partitions of the data object in the platform.
38. The method of claim 36 , further comprising:
creating an archived copy of the respective partition of the data object before merging or splitting the respective partition.
39. The method of claim 38 , further comprising:
updating reference information in the snapshot of the data object to point to a location where the archived copy of the respective partition is stored.
40. The method of claim 36 , wherein the snapshot manifest is created in an offline mode, and the method further comprises:
disabling access to a table; and
examining a namespace to determine which partitions of the data object form the table.
41. The method of claim 36 , wherein the snapshot manifest is created in an online mode, and the method further comprises:
causing the region servers associated with the identified one or more data nodes to flush data currently in memory into a table.
42. The method of claim 41 , wherein the platform continues to accept input/output operations from clients during creation of the snapshot manifest.
43. The method of claim 36 , further comprising:
backing up data in the platform by performing a MAPREDUCE job and based on the snapshot manifest, wherein the backing up step does not involve table manipulation commands.
44. The method of claim 36 , further comprising:
cloning a table based on the snapshot.
45. The method of claim 44 , wherein the cloning of the table comprises:
creating a copy of a table metadata; and
copying relevant partitions of the data object on each associated data node into a new directory on the associated data node.
46. The method of claim 36 , further comprising:
rolling back a table to a previous state based on the snapshot.
47. The method of claim 36 , wherein the causal inconsistency comprises data having been input into the platform but being unaccounted for in the snapshot.
48. The method of claim 36 , further comprising:
resolving the causal inconsistency by sending a request to a respective region server.
49. The method of claim 48 , wherein the request causes the respective region server to perform steps comprising:
adding an entry to a log for a memory flush; and
placing a marker in the log, wherein the marker indicates the creation of the snapshot.
50. The method of claim 49 , further comprising:
restoring a table based on the snapshot.
51. The method of claim 50 , wherein the restoring of the table comprises:
clearing the table; and
reenacting log entries or replaying the log.
52. The method of claim 36 , wherein the master node comprises an HBASE master node, the slave nodes comprise HBASE slave nodes, and the data object comprises a HADOOP table.