wsrep state API
API to dump and restore wsrep implementation state
Blueprint information
- Status:
- Not started
- Approver:
- Seppo Jaakola
- Priority:
- Essential
- Drafter:
- Alex Yurchenko
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Drafting
- Series goal:
- Accepted for trunk
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Sprints
Whiteboard
So we're facing with the need to dump, transfer and restore wsrep implementation state.
REQUIREMENTS
The only hard requirement is that state format is application agnostic. I.e. it should not assume anything about application.
APPROACH 1.
Technically wsrep implementation state can be just an opaque binary blob that application has to deal somehow with: save to persistent storage, transfer over the networks, etc. This eliminates any concerns about extensibility. Let's call it "Approach 1". However this maybe not the most convenient approach both for application and wsrep implementation:
a) From the application perspective binary data may be not the most suitable to incorporate into state snapshot.
w) From the wsrep implementation perspective there is still a problem of state serialization/
d) Opaque binary blob is inconvenient for debugging and recovery.
APPROACH 2.
Approach 2 is based on char string data encoding which is a subset of binary blob. Each element of wsrep implementation state is represented by a 0-terminated C char string. This takes care of serialization, is human-readable, easy to parse and can encode any information whilst staying completely opaque to the application. We also can add metadata rules to give it some structure without losing generality:
Let wsrep implementation state consist of a header followed by 0 or more data tables. State header consists of:
1) implementation ID string (to distinguish between different wsrep implementations)
2) version string (which ultimately determines the rest of the layout)
3) history UUID:seqno string.
Data table consists of
1) table name string
2) number of columns string (M)
3) number of rows string (N)
4) M column names strings
5) MxN data strings
Having this structure allows to easily represent the data as a set of annotated text or database tables. The latter will be very helpful in SST. Also, having well defined and annotated tables simplifies version compatibility.
