-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.txt
95 lines (65 loc) · 3.25 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
------------
Module names
------------
The network consists of Clients, Servers, and possibly an Arbitrator.
There is a module for each of these to implement its own logic.
There are modules to handle the communications between nodes - for example, a Client node needs to communicate with several Server nodes, so it will have several instance of the ClientServer module.
minder.pl - main script will determine whether to act as a Client, Server or Arbitrator.
GaleraArbitrator - controls the promotion of a db node to primary
ArbitratorServer - runs in the arbitrator, to communicate with servers
GaleraServer - communicates with the mysqld process, and manages it.
ServerArbitrator
Client
ClientServer
Wakeup
Config - the actual configuration
ClusterConfig - the module that interprets and encapsulates the configuration
Correspondent - parent class for the various corresponding modules
-------------------------------------------
The language that goes through the messages
-------------------------------------------
Every message has
sender receiver verb parameters
Every message descibes the (new) current state, and does not depend on the previous state.
For example, we never say "The state has changed." Instead we say "The current state is.."
Some messages need to be acknowledged with a reply or with ack.
If no acknowledgement is received within 3 seconds, the messages is re-sent.
There is no need to subscribe or connect. Messages will be sent to every node in the config file and no others.
Generic Verbs:
ack - this is an acknowledgement - no further action required.
Server->Arbitrator verbs
db_status_report (ack) sent regularly, or in response to request_status
Arbitrator->Server verbs
make_primary
request_status "Please send a status report now!"
Client->Server verbs
Server->Client verbs
db_status_report (ack) sent regularly
sender and receiver is the type, and the serial. These are identified in the config file.
Party types are:
dbserver - the pl script look after a mariadb server
wsrep_notify_cmd - the shell script triggered by galera
dbclient - the pl script minding a glb daemon
arbitrator -
command - commands entered by keyboard
wsrep_notify_cmd and the parameters of that
db_status {running} {primary} {group}
A status report sent from db node to arbitrator
Now, arbitrator wants to know if a db node is alive. All it can do is send a status request, which should be answered immediately.
status_request
set_primary An instructon from the arbitrator to set this cluster as primary.
status_summary a list of the status of all nodes
Human sends message to arbitrator:
status_summary
drain {node} - drain a node
Nodes must contact arbitrator first.
Arbitrator keeps a note of them, to return the messages.
A site-wide config file will be used, containing all the data we need.
That is, the IP address of the arbitrator, and of each db node.
And maybe more information to come.
Oh yes, which is the primary and secondary data centre.
-------------------------
Configuration.
The configuration of the entire setup is in the database.
Nodes only need to know how to connect to the database, then they have access to the config.
Nodes will store a local copy of the config, to be used in case they lose contact with the database.