Set Up High Availability¶
Add a second Flow Scheduler node that shares the database with the first, so that a standby takes over when the leader fails.
These steps turn an existing single node (node A) into a two-node cluster with a new node B. Repeat the node B steps for each further node. How the cluster behaves is described in High Availability.
Before you begin¶
- The MetaMiner Database (MMDB) is an external PostgreSQL database that every node can reach. High availability is supported only with an external PostgreSQL database.
- The Flow Scheduler runs on node A. See Enable the Flow Scheduler.
- Node B can run the same MetaMiner build as node A, with a MetaMiner Server (MMS) and the Flow Scheduler on the same host. Every node must run the same build.
- The clocks of all nodes are in sync (NTP).
- Each node reaches the shared PostgreSQL database and Tableau Server. Inbound, only the MMS port (49714 by default) is open; port 49716 stays closed, also between nodes.
- Node B has a valid MetaMiner licence under your licence terms.
- If users sign in with a Personal Access Token or SSO, Tableau Server trusts the source IP of every node. See Sign-In Options.
Set the HA settings in MMA, never in MetaMinerServer.properties
A Flow Scheduler setting in server\MetaMinerServer.properties is fixed at launch and does not follow the preferred node. Set the two per-node settings below in the MetaMiner Administrator (MMA) on each node, and every other Flow Scheduler setting once, in MMA on the preferred node.
Steps¶
Prepare node A¶
- In the web interface on node A, open Admin > Settings > Backup and click Back up this node. See Backup and Restore.
-
On node A, open MMA and choose Tools > FSS Configuration..., Properties tab. Type
ha.or the key name in Filter: and set these two settings, clicking Apply after each:Setting Value on node A ha.lease.enabledtruemms.url.localThis node's own MMS address, for example https://<node-a>:<port> -
Restart the Flow Scheduler on node A (
MetaMinerFSSin Windows Services). Node A takes the lease and becomes the leader. - Check that node A is the leader: in the web interface, Admin > HA / Nodes shows node A as leader with a fresh Last update.
Add node B¶
- Install MetaMiner on node B with the same build as node A. Do not start its services yet.
-
Copy these files from node A to node B, under
C:\Program Files\Infolytik\MetaMiner\server\, while node B is stopped:File or folder Action config\config.json, plusconfig\config.ecfandconfig\config.ekwhen presentCopy. Check that the database connection names the shared PostgreSQL host, never localhost. Copy the key file together with the encrypted file.config\mmext-services.jsonCopy. config-overrides.propertiesCopy, so that node B's Flow Scheduler starts with high availability on. config\saml\(when SSO is used)Copy the whole folder. config\apitoken.jsonDo not copy. API clients live in the shared database. See Upgrade from the Shared Token. data\,logs\,backups\,config-snapshots\,MetaMinerWebApps.iniDo not copy. They belong to node A. Never start a node with high availability off
A node with
ha.lease.enabledoff acts as the leader on its own, so two nodes would run the same flows. Copyingconfig-overrides.propertiesmakes node B start as a standby. -
On node B, open MMA, choose Preferences > Settings, General, select Enable Flow Scheduler (FSS) and save. If you use Personal Access Token sign-in, also add
flowscheduler.auth.pat.enabled=trueto node B'sserver\MetaMinerServer.properties(an MMS setting, not a Flow Scheduler setting). - Start MetaMiner on node B from MMA (Start Server). MMA starts MMS and then the Flow Scheduler, which joins as a standby.
-
On node B, in MMA Tools > FSS Configuration..., Properties tab, set the same two settings for this node and click Apply after each:
Setting Value on node B ha.lease.enabledtruemms.url.localNode B's own MMS address, for example https://<node-b>:<port>If node A has
ha.node.idset, give node B its own value. Left unset, it is the host name. -
Restart the Flow Scheduler on node B.
Choose the preferred node¶
- In the web interface, open Admin > HA / Nodes and click the star on the node that should normally lead.
- From now on, change every other Flow Scheduler setting once, in MMA on the preferred node. The other nodes take the new value and apply it at their next Flow Scheduler restart, so restart the Flow Scheduler on every node after a change. MMA refuses a shared setting saved on another node and names the preferred node.
- Drill a handover while you watch: click Make Leader on the standby, check that schedules keep firing and Leadership events records the change, then hand leadership back.
Also shared by the cluster
API clients, allowed environments and Flow Scheduler admins live in the shared database, so you set them once. Create API clients in MMA on the leader; on a standby the API client screen is read-only. A Tableau Server login changed through the Tableau Credentials API on one node reaches every node.
Verify¶
- Admin > HA / Nodes lists every node: one leader, the others standby, each with a fresh Last update.
-
On each node, the health page answers through MMS. Its
custom.mmsFailover.rolevalue isLEADERon one node andSTANDBYon the others:curl -s "https://<node>:<port>/api/flowscheduler/health" -
After Make Leader, the term in Leadership events goes up by one.
Troubleshooting¶
Both nodes show as standby
Neither node can write the lease. This is almost always connectivity to the shared PostgreSQL database. Check the database and the network from each node.
More cluster symptoms (leadership moving back and forth, a service stopping right after a restart): Troubleshooting.