{"id":7740,"date":"2017-08-03T10:41:11","date_gmt":"2017-08-03T08:41:11","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=7740"},"modified":"2017-08-03T15:32:59","modified_gmt":"2017-08-03T13:32:59","slug":"orchestratorraft-pre-release-3-0","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/orchestratorraft-pre-release-3-0","title":{"rendered":"orchestrator\/raft: Pre-Release 3.0"},"content":{"rendered":"

orchestrator<\/code> 3.0 Pre-Release<\/strong> is now available<\/a>. Most notable are Raft<\/strong> consensus, SQLite<\/strong> backend support, orchestrator-client<\/strong> no-binary-required client script.<\/p>\n

TL;DR<\/h3>\n

You may now set up high availability for orchestrator<\/code> via raft<\/code> consensus, without need to set up high availability for orchestrator<\/code>‘s backend MySQL servers (such as Galera\/InnoDB Cluster). In fact, you can run a orchestrator\/raft<\/code> setup using embedded SQLite<\/code> backend DB. Read on.<\/p>\n

orchestrator<\/code> still supports the existing shared backend DB paradigm; nothing dramatic changes if you upgrade to 3.0<\/strong> and do not configure raft<\/code>.<\/p>\n

orchestrator\/raft<\/h3>\n

Raft<\/a> is a consensus protocol, supporting leader election and consensus across a distributed system.\u00a0 In an orchestrator\/raft<\/code> setup orchestrator<\/code> nodes talk to each other via raft protocol, form consensus and elect a leader. Each orchestrator<\/code> node has its own dedicated<\/em> backend database. The backend databases do not speak to each other; only the orchestrator<\/code> nodes speak to each other.<\/p>\n

No MySQL replication setup needed; the backend DBs act as standalone servers. In fact, the backend server doesn’t have to be MySQL, and SQLite<\/code> is supported. orchestrator<\/code> now ships with SQLite<\/code> embedded, no external dependency needed.<\/p>\n

\"\"<\/a><\/p><\/blockquote>\n

In a orchestrator\/raft<\/code> setup, all orchestrator<\/code> nodes talk to each other. One and only one is elected as leader<\/em>. To become a leader a node must be part of a quorum<\/em>. On a 3<\/code> node setup, it takes 2<\/code> nodes to form a quorum. On a 5<\/code> node setup, it takes 3<\/code> nodes to form a quorum.<\/p>\n

Only the leader will run failovers. This much is similar to the existing shared-backend DB setup. However in a orchestrator\/raft<\/code> setup each node is independent, and each orchestrator<\/code> node runs discoveries<\/em>. This means a MySQL server in your topology will be routinely visited and probed by not one orchestrator<\/code> node, but by all 3<\/code> (or 5<\/code>, or what have you) nodes in your raft cluster.<\/p>\n

Any communication to orchestrator<\/code> must take place through the leader. One may not tamper directly with the backend DBs anymore, since the leader<\/code> is the one authoritative entity to replicate and announce changes to its peer nodes. See orchestrator-client<\/strong> section following.<\/p>\n

For details, please refer to the documentation:<\/p>\n