Starting the server > Linux | Manticore Search Manual

You can install and start Manticore easily in Ubuntu, Centos, Debian, Windows and MacOS or use Manticore as a docker container.

‹›

Ubuntu
Debian
Centos
Windows
MacOS
Docker

📋

wget https://repo.manticoresearch.com/manticore-repo.noarch.deb
sudo dpkg -i manticore-repo.noarch.deb
sudo apt update
sudo apt install manticore manticore-columnar-lib
sudo systemctl start manticore

wget https://repo.manticoresearch.com/manticore-repo.noarch.deb
sudo dpkg -i manticore-repo.noarch.deb
sudo apt update
sudo apt install manticore manticore-columnar-lib
sudo systemctl start manticore

sudo yum install https://repo.manticoresearch.com/manticore-repo.noarch.rpm
sudo yum install manticore manticore-columnar-lib
sudo systemctl start manticore

Download Windows archive from https://manticoresearch.com/downloads/
Extract all from the archive to C:\Manticore

C:\Manticore\bin\searchd --install --config C:\Manticore\sphinx.conf.in --servicename Manticore

Start Manticore from the Services snap-in of the Microsoft Management Console

brew install manticoresoftware/manticore/manticoresearch
brew services start manticoresearch

docker pull manticoresearch/manticore
docker run --name manticore -p9306:9306 -p9308:9308 -p9312:9312 -d manticoresearch/manticore

For persisting your data directory read how to use Manticore docker in production

By default Manticore is waiting for your connections on:

port 9306 for MySQL clients
port 9308 for HTTP/HTTPS connections
port 9312 for connections from other Manticore nodes and clients based on Manticore binary API

‹›

SQL
HTTP
PHP
Python
Javascript
Java

📋

mysql -h0 -P9306

HTTP is a stateless protocol so it doesn't require any special connection phase:

curl -s "http://localhost:9308/search"

// https://github.com/manticoresoftware/manticoresearch-php
require_once __DIR__ . '/vendor/autoload.php';
$config = ['host'=>'127.0.0.1','port'=>9308];
$client = new \Manticoresearch\Client($config);

// https://github.com/manticoresoftware/manticoresearch-python
import manticoresearch
config = manticoresearch.Configuration(
    host = "http://127.0.0.1:9308"
)
client =  manticoresearch.ApiClient(config)
indexApi = manticoresearch.IndexApi(client)
searchApi = manticoresearch.SearchApi(client)
utilsApi = manticoresearch.UtilsApi(client)

// https://github.com/manticoresoftware/manticoresearch-javascript
var Manticoresearch = require('manticoresearch');
var client= new Manticoresearch.ApiClient()
client.basePath="http://127.0.0.1:9308";
indexApi = new Manticoresearch.IndexApi(client);
searchApi = new Manticoresearch.SearchApi(client);
utilsApi = new Manticoresearch.UtilsApi(client);

// https://github.com/manticoresoftware/manticoresearch-java
import com.manticoresearch.client.*;
import com.manticoresearch.client.model.*;
import com.manticoresearch.client.api.*;
...
ApiClient client = Configuration.getDefaultApiClient();
client.setBasePath("http://127.0.0.1:9308");
...
IndexApi indexApi = new IndexApi(client);
SearchApi searchApi = new UtilsApi(client);
UtilsApi utilsApi = new UtilsApi(client);

Let's now create an index called "products" with 2 fields:

title - full-text field which will contain our product's title
price - of type "float"

‹›

SQL
HTTP
PHP
Python
Javascript
Java

📋

create table products(title text, price float) morphology='stem_en';

POST /sql -d "mode=raw&query=create table products(title text, price float) morphology='stem_en'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'float'],
],['morphology' => 'stem_en']);

utilsApi.sql('mode=raw&query=create table products(title text, price float) morphology=\'stem_en\'')

res = await utilsApi.sql('mode=raw&query=create table products(title text, price float) morphology=\'stem_en\'');

utilsApi.sql("mode=raw&query=create table products(title text, price float) morphology='stem_en'");

‹›

Response

Query OK, 0 rows affected (0.02 sec)

Let's now add few documents to the index:

‹›

SQL
HTTP
PHP
Python
Javascript
Java

📋

insert into products(title,price) values ('Crossbody Bag with Tassel', 19.85), ('microfiber sheet set', 19.99), ('Pet Hair Remover Glove', 7.99);

"id":0 forces automatic ID generation.

POST /insert
{
  "index":"products",
  "doc":
  {
    "title" : "Crossbody Bag with Tassel",
    "price" : 19.85
  }
}


POST /insert
{
  "index":"products",
  "doc":
  {
    "title" : "microfiber sheet set",
    "price" : 19.99
  }
}

POST /insert
{
  "index":"products",
  "doc":
  {
    "title" : "Pet Hair Remover Glove",
    "price" : 7.99
  }
}

$index->addDocuments([
        ['title' => 'Crossbody Bag with Tassel', 'price' => 19.85],
        ['title' => 'microfiber sheet set', 'price' => 19.99],
        ['title' => 'Pet Hair Remover Glove', 'price' => 7.99]
]);

indexApi.insert({"index" : "test", "doc" : {"title" : "Crossbody Bag with Tassel", "price" : 19.85}})
indexApi.insert({"index" : "test", "doc" : {"title" : "microfiber sheet set", "price" : 19.99}})
indexApi.insert({"index" : "test", "doc" : {"title" : "Pet Hair Remover Glove", "price" : 7.99}})

res = await indexApi.insert({"index" : "test", "doc" : {"title" : "Crossbody Bag with Tassel", "price" : 19.85}});
res = await indexApi.insert({"index" : "test", "doc" : {"title" : "microfiber sheet set", "price" : 19.99}});
res = await indexApi.insert({"index" : "test", doc" : {"title" : "Pet Hair Remover Glove", "price" : 7.99}});

InsertDocumentRequest newdoc = new InsertDocumentRequest();
HashMap<String,Object> doc = new HashMap<String,Object>(){{
    put("title","Crossbody Bag with Tassel");
    put("price",19.85);
}};
newdoc.index("products").setDoc(doc);
sqlresult = indexApi.insert(newdoc);

newdoc = new InsertDocumentRequest();
doc = new HashMap<String,Object>(){{
    put("title","microfiber sheet set");
    put("price",19.99);
}};
newdoc.index("products").setDoc(doc);
sqlresult = indexApi.insert(newdoc);

newdoc = new InsertDocumentRequest();
doc = new HashMap<String,Object>(){{
    put("title","Pet Hair Remover Glove");
    put("price",7.99);
 }};
newdoc.index("products").setDoc(doc);
indexApi.insert(newdoc);

‹›

Response

Query OK, 3 rows affected (0.01 sec)

Let's find one of the documents. The query we will use is 'remove hair'. As you can see it finds document with title 'Pet Hair Remover Glove' and highlights 'Hair remover' in it even though the query has "remove", not "remover". This is because when we created the index we turned on using English stemming (morphology "stem_en").

‹›

SQL
HTTP
PHP
Python
javascript
Java

📋

select id, highlight(), price from products where match('remove hair');

POST /search
{
  "index": "products",
  "query": { "match": { "title": "remove hair" } },
  "highlight":
  {
    "fields": ["title"]
  }
}

$result = $index->search('@title remove hair')->highlight(['title'])->get();
foreach($result as $doc)
{
    echo "Doc ID: ".$doc->getId()."\n";
    echo "Doc Score: ".$doc->getScore()."\n";
    echo "Document fields:\n";
    print_r($doc->getData());
    echo "Highlights: \n";
    print_r($doc->getHighlight());
}

searchApi.search({"index":"myindex","query":{"query_string":"@title remove hair"},"highlight":{"fields":["title"]}})

res = await searchApi.search({"index":"myindex","query":{"query_string":"@title remove hair"}"highlight":{"fields":["title"]}});


query = new HashMap<String,Object>();
query.put("query_string","@title remove hair");
searchRequest = new SearchRequest();
searchRequest.setIndex("forum");
searchRequest.setQuery(query);
HashMap<String,Object> highlight = new HashMap<String,Object>(){{
    put("fields",new String[] {"title"});

}};
searchRequest.setHighlight(highlight);
searchResponse = searchApi.search(searchRequest);

‹›

Response

+---------------------+-------------------------------+----------+
| id                  | highlight()                   | price    |
+---------------------+-------------------------------+----------+
| 1513686608316989452 | Pet <strong>Hair Remover</strong> Glove | 7.990000 |
+---------------------+-------------------------------+----------+
1 row in set (0.00 sec)

{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 1,
    "hits": [
      {
        "_id": "1513686608316989452",
        "_score": 1680,
        "_source": {
          "price": 7.99,
          "title": "Pet Hair Remover Glove"
        },
        "highlight": {
          "title": [
            "Pet <strong>Hair Remover</strong> Glove"
          ]
        }
      }
    ]
  }
}

Doc ID: 1513686608316989452
Doc Score: 1680
Document fields:
Array
(
    [price] => 7.99
    [title] => Pet Hair Remover Glove
)
Highlights:
Array
(
    [title] => Array
        (
            [0] => Pet <strong>Hair Remover</strong> Glove
        )
)

{'hits': {'hits': [{u'_id': u'1513686608316989452',
                    u'_score': 1680,
                    u'_source': {u'title': u'Pet Hair Remover Glove', u'price':7.99},
                    u'highlight':{u'title':[u'Pet <strong>Hair Remover</strong> Glove']}}}],
          'total': 1},
 'profile': None,
 'timed_out': False,
 'took': 0}

{"hits": {"hits": [{"_id": "1513686608316989452",
                    "_score": 1680,
                    "_source": {"title": "Pet Hair Remover Glove", "price":7.99},
                    "highlight":{"title":["Pet <strong>Hair Remover</strong> Glove"]}}],
          "total": 1},
 "profile": None,
 "timed_out": False,
 "took": 0}

class SearchResponse {
    took: 84
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        maxScore: null
        hits: [{_id=1513686608316989452, _score=1, _source={price=7.99, title=Pet Hair Remover Glove}, highlight={title=[Pet <strong>Hair Remover</strong> Glove]}}]
        aggregations: null
    }
    profile: null
}

Let's assume we now want to update the document - change the price to 18.5. This can be done by filtering by any field, but normally you know the document id and update something based on that.

‹›

SQL
HTTP
PHP
Python
javascript
Java

📋

update products set price=18.5 where id = 1513686608316989452;

POST /update
{
  "index": "products",
  "id": 1513686608316989452,
  "doc":
  {
    "price": 18.5
  }
}

$doc = [
    'body' => [
        'index' => 'products',
        'id' => 2,
        'doc' => [
            'price' => 18.5
        ]
    ]
];

$response = $client->update($doc);

indexApi = api = manticoresearch.IndexApi(client)
indexApi.update({"index" : "products", "id" : 1513686608316989452, "doc" : {"price":18.5}})

res = await indexApi.update({"index" : "products", "id" : 1513686608316989452, "doc" : {"price":18.5}});

UpdateDocumentRequest updateRequest = new UpdateDocumentRequest();
doc = new HashMap<String,Object >(){{
    put("price",18.5);
}};
updateRequest.index("products").id(1513686608316989452L).setDoc(doc);
indexApi.update(updateRequest);

‹›

Response

Query OK, 1 row affected (0.00 sec)

Let's now delete all documents with price lower than 10.

‹›

SQL
HTTP
PHP
Python
javascript
Java

📋

delete from products where price < 10;

POST /delete
{
  "index": "products",
  "query":
  {
    "range":
    {
      "price":
      {
        "lte": 10
      }
    }
  }
}

$result = $index->deleteDocuments(new \Manticoresearch\Query\Range('price',['lte'=>10]));

indexApi.delete({"index" : "products", "query": {"range":{"price":{"lte":10}}}})

res = await indexApi.delete({"index" : "products", "query": {"range":{"price":{"lte":10}}}});

DeleteDocumentRequest deleteRequest = new DeleteDocumentRequest();
query = new HashMap<String,Object>();
query.put("range",new HashMap<String,Object>(){{
    put("range",new HashMap<String,Object>(){{
        put("lte",10);
    }});
}});
deleteRequest.index("products").setQuery(query);
indexApi.delete(deleteRequest);

‹›

Response

Query OK, 1 row affected (0.00 sec)

{
  "_index": "products",
  "deleted": 1
}

Array
(
    [_index] => products
    [deleted] => 1
)

️Starting the server

Manticore Search server can be started in several ways, depending on how it was installed.

Quick start guide In Linux

When Manticore Search is installed using DEB or RPM packages, the searchd process can be run and managed by operating system's init system. Most Linux versions now use systemd, while older releases use SysV init.

If you are not sure about the type of the init system your platform use, run:

ps --no-headers -o comm 1

After the installation the Manticore Search service is not started automatically. To start Manticore run the following command:

sudo systemctl start manticore

To stop Manticore run the following command:

sudo systemctl stop manticore

The Manticore service is set to run at boot. You can check it by running:

sudo systemctl is-enabled manticore

If you want to disable Manticore starting at boot time run:

sudo systemctl disable manticore

To enable Manticore to start at boot, run:

sudo systemctl enable manticore

searchd process logs startup information in systemd journal. If systemd logging is enabled you can view the logged information with the following command:

sudo journalctl --unit manticore

systemctl set-environment _ADDITIONAL_SEARCHD_PARAMS allows you to specify custom startup flags Manticore Search daemon should be started with. See the full list here.

For example, to start Manticore with debug logging level you can run:

systemctl set-environment _ADDITIONAL_SEARCHD_PARAMS='--logdebug'
systemctl restart manticore

To undo it run:

systemctl set-environment _ADDITIONAL_SEARCHD_PARAMS=''
systemctl restart manticore

Note, systemd environment variables get reset on server reboot.

Manticore can be started and stopped using service commands:

sudo service manticore start
sudo service manticore stop

To enable the sysV service at boot on RedHat systems run:

chkconfig manticore on

To enable the sysV service at boot on Debian systems (including Ubuntu) run:

update-rc.d manticore defaults

Please note that searchd is started by the init system under manticore user and all files created by the server will be owned by this user. If searchd is started under ,for example, root user, the permissions of files will be changed which may lead to issues when running again searchd as service.

️Starting the server Manually

You can also start Manticore Search by calling searchd (Manticore Search server binary) directly:

searchd [OPTIONS]

Note that without setting a path to the configuration file searchd will try to find it in several locations, depending on the operation system.

The options available to searchd in all operation systems are:

--help (-h for short) lists all of the parameters that can be called in your particular build of searchd.
--version (-v for short) shows Manticore Search version information.
--config <file> (-c <file> for short) tells searchd to use the given file as its configuration.
--stop is used to asynchronously stop searchd, using the details of the PID file as specified in the Manticore configuration file, so you may also need to confirm to searchd which configuration file to use with the --config option. Example:

$ searchd --config /etc/manticoresearch/manticore.conf --stop

--stopwait is used to synchronously stop searchd. --stop essentially tells the running instance to exit (by sending it a SIGTERM) and then immediately returns. --stopwait will also attempt to wait until the running searchd instance actually finishes the shutdown (eg. saves all the pending attribute changes) and exits. Example:

$ searchd --config /etc/manticoresearch/manticore.conf --stopwait

Possible exit codes are as follows:

0 on success
1 if connection to running searchd server failed
2 if server reported an error during shutdown
3 if server crashed during shutdown
--status command is used to query running searchd instance status using the connection details from the (optionally) provided configuration file. It will try to connect to running instance using the first found UNIX socket or TCP port from the configuration file. On success it will query for a number of status and performance counter values and print them. You can also use SHOW STATUS command to access the very same counters via SQL protocol. Examples:
```
$ searchd --status
$ searchd --config /etc/manticoresearch/manticore.conf --status
```
--pidfile is used to explicitly force using a PID file (where the searchd process identification number is stored) despite any other debugging options that say otherwise (for instance, --console). This is a debugging option.
```
$ searchd --console --pidfile
```
--console is used to force searchd into console mode; typically Manticore runs as a conventional server application and logs information into log files (as specified in configuration file). Sometimes though, when debugging issues in the configuration or the server itself or trying to diagnose hard-to-track-down problems it may be easier to force it to dump information directly to the console/command line from which it is being called. Running in console mode also means that the process will not be forked (so searches are done in sequence) and logs will not be written to. (It should be noted that console mode is not the intended method for running searchd.) You can invoke so:
```
$ searchd --config /etc/manticoresearch/manticore.conf --console
```
--logdebug, --logreplication, --logdebugv, and --logdebugvv options enable additional debug output in the server log. They differ by the logging verboseness level. These are debugging options, they pollute the log a lot, and thus they should not be normally enabled. (The normal use case for these is to enable them temporarily on request, to assist with some particularly complicated debugging session.)
--iostats is used in conjunction with the logging options (the query_log will need to have been activated in manticore.conf) to provide more detailed information on a per-query basis as to the input/output operations carried out in the course of that query, with a slight performance hit and a little bit bigger logs. The IO statistics don't include information about IO operations for attributes, as these are loaded with mmap. To enable it you can start searchd so:
```
$ searchd --config /etc/manticoresearch/manticore.conf --iostats
```
--cpustats is used to provide actual CPU time report (in addition to wall time) in both query log file (for every given query) and status report (aggregated). It depends on clock_gettime() Linux system call or falls back to less precise call on certain systems. You might start searchd thus:
```
$ searchd --config /etc/manticoresearch/manticore.conf --cpustats
```
--port portnumber (-p for short) is used to specify the port that Manticore should listen on to accept binary protocol requests, usually for debugging purposes. This will usually default to 9312, but sometimes you need to run it on a different port. Specifying it on the command line will override anything specified in the configuration file. The valid range is 0 to 65535, but ports numbered 1024 and below usually require a privileged account in order to run. An example of usage:
```
  $ searchd --port 9313
```
--listen ( address ":" port | port | path ) [ ":" protocol ] (or -l for short) Works as --port, but allow you to specify not only the port, but full path, as IP address and port, or Unix-domain socket path, that searchd will listen on. In other words, you can specify either an IP address (or hostname) and port number or just a port number or Unix socket path. If you specify port number, but not the address searchd will listen on all network interfaces. Unix path is identified by a leading slash. As the last param you can also specify a protocol handler (listener) to be used for connections on this socket. Supported protocol values are 'sphinx' and 'mysql' (MySQL protocol used since 4.1).
--force-preread forbids the server to serve any incoming connection until prereading of index files completes. By default, at startup the server accepts connections while index files are lazy loaded into memory. This opens extends the behavior and makes it wait until the files are loaded.
--index <index> (or -i <index> for short) forces this instance of searchd to only serve the specified index. Like --port, above, this is usually for debugging purposes; more long-term changes would generally be applied to the configuration file itself.
--strip-path strips the path names from all the file names referenced from the index (stopwords, wordforms, exceptions, etc). This is useful for picking up indexes built on another machine with possibly different path layouts.
--replay-flags=<OPTIONS> switch can be used to specify a list of extra binary log replay options. The supported options are:
- accept-desc-timestamp, ignore descending transaction timestamps and replay such transactions anyway (the default behavior is to exit with an error).
- ignore-open-errors, ignore missing binlog files (the default behavior is to exit with an error).
- ignore-trx-errors, ignore any transaction errors and skip current binlog file (the default behavior is to exit with an error).
- ignore-all-errors, ignore any errors described above (the default behavior is to exit with an error). Example:
```
$ searchd --replay-flags=accept-desc-timestamp
```
--coredump is used to enable saving a core file or a minidump of the server on crash. Disabled by default to speed up of server restart on crash. This is useful for debugging purposes.
```
$ searchd --config /etc/manticoresearch/manticore.conf --coredump
```
--new-cluster bootstraps a replication cluster and makes the server a reference node with cluster restart protection. On Linux you can also run manticore_new_cluster. It will start Manticore in --new-cluster mode via systemd.
--new-cluster-force bootstraps a replication cluster and makes the server a reference node bypassing cluster restart protection. On Linux you can also run manticore_new_cluster --force. It will start Manticore in --new-cluster-force mode via systemd.

There are some options for searchd that are specific to Windows platforms, concerning handling as a service, and are only available in Windows binaries.

Note that in Windows searchd will default to --console mode, unless you install it as a service.

--install installs searchd as a service into the Microsoft Management Console (Control Panel / Administrative Tools / Services). Any other parameters specified on the command line, where --install is specified will also become part of the command line on future starts of the service. For example, as a part of calling searchd, you will likely also need to specify the configuration file with --config, and you would do that as well as specifying --install. Once called, the usual start/stop facilities will become available via the management console, so any methods you could use for starting, stopping and restarting services would also apply to searchd. Example:
```
C:\WINDOWS\system32> C:\Manticore\bin\searchd.exe --install
 --config C:\Manticore\manticore.conf
```

If you want to have the I/O stats every time you start searchd, you need to specify its option on the same line as the --install command thus:

C:\WINDOWS\system32> C:\Manticore\bin\searchd.exe --install
   --config C:\Manticore\manticore.conf --iostats

--delete removes the service from the Microsoft Management Console and other places where services are registered, after previously installed with --install. Note, this does not uninstall the software or delete the indexes. It means the service will not be called from the services systems, and will not be started on the machine's next start. If currently running as a service, the current instance will not be terminated (until the next reboot, or until searchd is called with --stop). If the service was installed with a custom name (with --servicename), the same name will need to be specified with --servicename when calling to uninstall. Example:
```
C:\WINDOWS\system32> C:\Manticore\bin\searchd.exe --delete
```
--servicename <name> applies the given name to searchd when installing or deleting the service, as would appear in the Management Console; this will default to searchd, but if being deployed on servers where multiple administrators may log into the system, or a system with multiple searchd instances, a more descriptive name may be applicable. Note that unless combined with --install or --delete, this option does not do anything. Example:
```
C:\WINDOWS\system32> C:\Manticore\bin\searchd.exe --install
 --config C:\Manticore\manticore.conf --servicename ManticoreSearch
```
--ntservice is the option that is passed by the Management Console to searchd to invoke it as a service on Windows platforms. It would not normally be necessary to call this directly; this would normally be called by Windows when the service would be started, although if you wanted to call this as a regular service from the command-line (as the complement to --console) you could do so in theory.
--safetrace forces searchd to only use system backtrace() call in crash reports. In certain (rare) scenarios, this might be a "safer" way to get that report. This is a debugging option.
--nodetach switch (Linux only) tells searchd not to detach into background. This will also cause log entry to be printed out to console. Query processing operates as usual. This is a debugging option and might also be useful when you run Manticore in a docker container to capture its output.

searchd supports a number of signals:

SIGTERM - Initiates a clean shutdown. New queries will not be handled, but queries that are already started will not be forcibly interrupted.
SIGHUP - Initiates indexes rotation. Depending on the value of seamless_rotate setting, new queries might be shortly stalled; clients will receive temporary errors.
SIGUSR1 - Forces reopen of searchd log and query log files, letting you implement log file rotation.

In Linux In Docker

Quick start guide

Install and start Manticore

Connect to Manticore

Create an index

Add documents

Search

Update

Delete

Starting the server

Starting Manticore in Linux

Starting and stopping using systemd

Custom startup flags using systemd

Starting and stopping using service

Starting Manticore manually

searchd command line options

Signals