wsrep state API

Registered by Alex Yurchenko on 2009-12-18

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

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/deserialization which involves taking care of endianness and alignment issues.
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.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.