ALTER CLUSTER <cluster_name> ADD <table_name> adds an existing local table to the cluster. The node which receives the ALTER query sends the table to the other nodes in the cluster. All the local tables with the same name on the other nodes of the cluster get replaced with the new table.
After the table is replicated, write statements can be performed on any node but table name must be prefixed with the cluster name like INSERT INTO <clusterName>:<table_name>.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
ALTER CLUSTER click_query ADD clicks_daily_index{u'error': u'', u'total': 0, u'warning': u''}ALTER CLUSTER <cluster_name> DROP <table_name> forgets about a local table, i.e., it doesn't remove the table files on the nodes but just makes it an active non-replicated table.
After a table is removed from a cluster, it becomes a 'local' table and write statements must use just the table name as INSERT INTO <table_name>, without the cluster prefix.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
ALTER CLUSTER posts DROP weekly_index{u'error': u'', u'total': 0, u'warning': u''}ALTER CLUSTER <cluster_name> UPDATE nodes statement updates node lists on each node of the cluster to include every active node in the cluster. See Joining a cluster for more info on node lists.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
ALTER CLUSTER posts UPDATE nodes{u'error': u'', u'total': 0, u'warning': u''}For example, when the cluster was initially created, the list of nodes used for rejoining the cluster was 10.10.0.1:9312,10.10.1.1:9312. Since then other nodes joined the cluster and now we have the following active nodes: 10.10.0.1:9312,10.10.1.1:9312,10.15.0.1:9312,10.15.0.3:9312.
But the list of nodes used for rejoining the cluster is still the same. Running the ALTER CLUSTER ... UPDATE nodes copies the list of active nodes to the list of nodes used to rejoin on restart. After this, the list of nodes used on restart includes all the active nodes in the cluster.
Both lists of nodes can be viewed using Cluster status statement (cluster_post_nodes_set and cluster_post_nodes_view).
To remove a node from a replication cluster you need to:
- stop the node
- remove info about the cluster in
<data_dir>/manticore.json(/var/lib/manticore/manticore.jsonin most cases) on the node you've stopped - run
ALTER CLUSTER cluster_name UPDATE nodeson any other node
After this the other nodes will forget about the detached node and the node will forget about the cluster. It won't impact tables neither in the cluster nor on the detached node.
Node status outputs, among other information, cluster status variables.
The output format is cluster_name_variable_name variable_value. Most of them are described in Galera Documentation Status Variables. Additionally we display:
- cluster_name - name of the cluster
- node_state - current state of the node:
closed,destroyed,joining,donor,synced - indexes_count - number of tables managed by the cluster
- indexes - list of table names managed by the cluster
- nodes_set - list of nodes in the cluster defined with cluster
CREATE,JOINorALTER UPDATEcommands - nodes_view - actual list of nodes in cluster which this node sees
- SQL
- JSON
- PHP
- Python
- javascript
- Java
SHOW STATUS+----------------------------+-------------------------------------------------------------------------------------+
| Counter | Value |
+----------------------------+-------------------------------------------------------------------------------------+
| cluster_name | post |
| cluster_post_state_uuid | fba97c45-36df-11e9-a84e-eb09d14b8ea7 |
| cluster_post_conf_id | 1 |
| cluster_post_status | primary |
| cluster_post_size | 5 |
| cluster_post_local_index | 0 |
| cluster_post_node_state | synced |
| cluster_post_indexes_count | 2 |
| cluster_post_indexes | pq1,pq_posts |
| cluster_post_nodes_set | 10.10.0.1:9312 |
| cluster_post_nodes_view | 10.10.0.1:9312,10.10.0.1:9320:replication,10.10.1.1:9312,10.10.1.1:9320:replication |