The table can be emptied with a TRUNCATE TABLE SQL statement or with a truncate() PHP client function.
Here is the syntax for the SQL statement:
TRUNCATE TABLE table_name [WITH RECONFIGURE]When this statement is executed, it clears the RT table completely. It disposes the in-memory data, unlinks all the table data files, and releases the associated binary logs.
A table can also be emptied with DELETE FROM index WHERE id>0, but it's not recommended as it's slower than TRUNCATE.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
TRUNCATE TABLE products;POST /cli -d "TRUNCATE TABLE products"$params = [ 'table' => 'products' ];
$response = $client->indices()->truncate($params);utilsApi.sql('TRUNCATE TABLE products')res = await utilsApi.sql('TRUNCATE TABLE products');utilsApi.sql("TRUNCATE TABLE products");utilsApi.Sql("TRUNCATE TABLE products");Query OK, 0 rows affected (0.02 sec){
"total":0,
"error":"",
"warning":""
}Array(
[total] => 0
[error] =>
[warning] =>
){u'error': u'', u'total': 0, u'warning': u''}{"total":0,"error":"","warning":""}{total=0, error=, warning=}{total=0, error="", warning=""}One of the possible uses of this command is before attaching a table.
When RECONFIGURE option is used new tokenization, morphology, and other text processing settings specified in the config take effect after the table gets cleared. In case the schema declaration in config is different from the table schema the new schema from config got applied after table get cleared.
With this option clearing and reconfiguring a table becomes one atomic operation.
- SQL
- HTTP
- PHP
- Python
- javascript
- Java
- C#
TRUNCATE TABLE products with reconfigure;POST /cli -d "TRUNCATE TABLE products with reconfigure"$params = [ 'table' => 'products', 'with' => 'reconfigure' ];
$response = $client->indices()->truncate($params);utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE')res = await utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE');utilsApi.sql("TRUNCATE TABLE products WITH RECONFIGURE");utilsApi.Sql("TRUNCATE TABLE products WITH RECONFIGURE");Query OK, 0 rows affected (0.02 sec){
"total":0,
"error":"",
"warning":""
}Array(
[total] => 0
[error] =>
[warning] =>
){u'error': u'', u'total': 0, u'warning': u''}{"total":0,"error":"","warning":""}{total=0, error=, warning=}{total=0, error="", warning=""}Manticore Search is a highly distributed system that provides all the necessary components to create a highly available and scalable database for search. This includes:
- distributed table for sharding
- Mirroring for high availability
- Load balancing for scalability
- Replication for data safety
Manticore Search offers great flexibility in terms of how you set up your cluster. There are no limitations, so it's up to you to design your cluster according to your needs. Simply learn about the tools mentioned above and use them to achieve your desired goal.
To add a new node to a cluster, simply start another instance of Manticore and ensure that it is accessible by the other nodes in the cluster. Connect the new node to the rest of the cluster using a distributed table and ensure data safety with replication.
To understand how to add a distributed table with remote agents, it is important to first have a basic understanding of distributed tables In this article, we will focus on how to use a distributed table as the basis for creating a cluster of Manticore instances.
Here is an example of how to split data over 4 servers, each serving one of the shards:
- ini
table mydist {
type = distributed
agent = box1:9312:shard1
agent = box2:9312:shard2
agent = box3:9312:shard3
agent = box4:9312:shard4
}In the event of a server failure, the distributed table will still work, but the results from the failed shard will be missing.
Now that we've added mirrors, each shard is found on 2 servers. By default, the master (the searchd instance with the distributed table) will randomly pick one of the mirrors.
The mode used for picking mirrors can be set using the ha_strategy setting. In addition to the default random mode there's also ha_strategy = roundrobin.
More advanced strategies based on latency-weighted probabilities include noerrors and nodeads. These not only take out mirrors with issues but also monitor response times and do balancing. If a mirror responds slower (for example, due to some operations running on it), it will receive fewer requests. When the mirror recovers and provides better times, it will receive more requests.
- ini
table mydist {
type = distributed
agent = box1:9312|box5:9312:shard1
agent = box2:9312:|box6:9312:shard2
agent = box3:9312:|box7:9312:shard3
agent = box4:9312:|box8:9312:shard4
}