Setting up replication

Manticore Search can replicate write transactions (INSERT, REPLACE, DELETE, TRUNCATE, UPDATE) in real-time tables to other nodes in a cluster.

To use replication, you need to ensure:

• Manticore Search is running in RT mode (data_dir is set in the configuration)
• listen includes a port range for the replication protocol (at least 2 ports per cluster)
• listen includes a port for the SphinxAPI protocol (used for node communication)
• listen includes a port for mysql41 protocol (to execute cluster SQL statements)
• Optionally set server_id to a unique value per node (auto-generated if omitted)
• Optionally set node_address to an accessible IP if not specified in listen

Let's look at the configuration of our two Manticore nodes:

cat /etc/manticoresearch/manticore1.conf

cat /etc/manticoresearch/manticore2.conf

Key configuration details:

• Node 1 listens on ports 9306 (MySQL), 9308 (HTTP), 9312 (SphinxAPI), and 9350-9359 (replication)
• Node 2 listens on ports 9307 (MySQL), 9309 (HTTP), 9313 (SphinxAPI), and 9360-9369 (replication)
• Each node has a unique server_id and separate data_dir
• node_address is set to ensure nodes can find each other

Let's connect to the first node:

mysql -P 9306 -h0

Creating a cluster and adding tables

Let's create a new replication cluster:

CREATE CLUSTER posts;

To verify the cluster was created, use SHOW STATUS:

SHOW STATUS LIKE 'cluster%';

You can see the cluster information in the status fields. Now let's create a real-time table:

CREATE TABLE testrt (title text, content text, gid uint);

Insert some data into the table:

INSERT INTO testrt VALUES(1,'List of HP business laptops','Elitebook Probook',10);

SELECT * FROM testrt;

Now let's add the table to the cluster so it can be replicated:

ALTER CLUSTER posts ADD testrt;

Verify the table was added to the cluster:

SHOW STATUS LIKE 'cluster_posts_indexes';

Important: Once a table is part of a cluster, all write statements (INSERT, REPLACE, DELETE, TRUNCATE, UPDATE) must use the cluster_name:table_name format. This ensures changes are propagated to all replicas.

Let's try inserting without the cluster prefix:

INSERT INTO testrt VALUES(2,'List of Dell business laptops','Latitude Precision Vostro',10);

We get an error — Manticore rejects writes to a clustered table without the cluster prefix. The correct way is to prepend the cluster name:

INSERT INTO posts:testrt VALUES(2,'List of Dell business laptops','Latitude Precision Vostro',10);

SELECT * FROM testrt;

Joining a node to the cluster

Let's switch to the second node:

exit;

mysql -P 9307 -h0

This node is not in our cluster yet, so it doesn't have the test table:

SELECT * FROM testrt;

To join an existing cluster, use JOIN CLUSTER with the cluster name and the address of any node already in the cluster:

JOIN CLUSTER posts AT '127.0.0.1:9312';

The JOIN CLUSTER command works synchronously and completes as soon as the node receives all data from the cluster.

Now let's check the replicated data:

SELECT * FROM testrt;

All data has been successfully replicated. Replication is multi-master, so writes to any node will be propagated to all other nodes. Let's insert from this node:

INSERT INTO posts:testrt VALUES(3,'List of Dell gaming laptops','Inspiron Alienware',20);

SELECT * FROM testrt;

Now switch back to our first node to verify replication:

exit;

mysql -P 9306 -h0

SELECT * FROM testrt;

The changes were replicated successfully. Let's also check the cluster status to see both nodes:

SHOW STATUS LIKE 'cluster_posts%';

The cluster_posts_nodes_view field shows all active nodes in the cluster.

Managing and removing cluster tables

You can update the node list across all cluster members using:

ALTER CLUSTER posts UPDATE nodes;

This ensures all nodes have an up-to-date list of cluster members, which is useful when nodes are added or removed.

Now let's remove our table from the cluster:

ALTER CLUSTER posts DROP testrt;

SHOW STATUS LIKE 'cluster_posts_indexes';

The table is no longer replicated. It has become a local non-replicated table:

INSERT INTO testrt VALUES(4,'Lenovo laptops list','Yoga IdeaPad',30);

No error about missing cluster prefix, confirming testrt is no longer in the cluster.

SELECT * FROM testrt;

Let's verify the changes were NOT replicated to the second node:

exit;

mysql -P 9307 -h0

SELECT * FROM testrt;

As expected, the insert was not replicated.

To remove a cluster completely, use DELETE CLUSTER:

DELETE CLUSTER posts;

SHOW STATUS LIKE 'cluster%';

The cluster is removed from all nodes, but tables remain intact as local non-replicated tables.

SELECT * FROM testrt;

Let's verify on the other node too:

exit;

mysql -P 9306 -h0

SHOW STATUS LIKE 'cluster%';

The cluster has been fully removed from both nodes.