Удалённая таблица в Manticore Search представлена префиксом agent в определении распределённой таблицы. Распределённая таблица может включать сочетание локальных и удалённых таблиц. Если локальные таблицы не указаны, распределённая таблица будет полностью удалённой и будет выступать только как прокси. Например, у вас может быть экземпляр Manticore, который слушает несколько портов и обслуживает разные протоколы, а затем перенаправляет запросы на серверы backend, которые принимают соединения только через внутренний бинарный протокол Manticore, используя постоянные соединения для уменьшения накладных расходов при установлении соединений.
Хотя распределённая таблица, состоящая только из удалённых, сама не содержит локальных таблиц, она всё равно потребляет ресурсы машины, поскольку должна выполнять окончательные вычисления, такие как слияние результатов и вычисление итоговых агрегированных значений.

agent = address1 [ | address2 [...] ][:table-list]
agent = address1[:table-list [ | address2[:table-list [...] ] ] ]

Директива agent объявляет удалённых агентов, которые опрашиваются каждый раз при поиске в окружающей распределённой таблице. Эти агенты фактически являются указателями на сетевые таблицы. Значение, указанное в директиве, включает адрес и может также содержать несколько альтернатив (зеркал агентов) либо только для адреса, либо для адреса вместе со списком таблиц.

Спецификация адреса должна быть одной из следующих:

address = hostname[:port] # eg. server2:9312
address = /absolute/unix/socket/path # eg. /var/run/manticore2.sock

hostname — это имя удалённого хоста, port — удалённый TCP-порт, table-list — это список имён таблиц, разделённых запятыми, а квадратные скобки [] обозначают необязательное условие.

Если имя таблицы опущено, предполагается, что это та же таблица, где определена эта строка. Другими словами, при определении агентов для распределённой таблицы 'mycoolindex' можно просто указать адрес, и будет предполагаться, что запрос идёт к таблице mycoolindex на конечных точках агента.

Если номер порта опущен, считается, что он равен 9312. Если он задан, но недопустим (например, 70000), агент будет пропущен.

Вы можете направлять каждого агента к одной или нескольким удалённым таблицам, расположенным на одном или нескольких сетевых серверах без ограничений. Это позволяет несколько различных режимов использования:

• Шардинг по нескольким серверам агентов и создание произвольной топологии кластера
• Шардинг по нескольким серверам агентов, зеркалированным для высокой доступности и балансировки нагрузки
• Шардинг внутри localhost для использования нескольких ядер (хотя проще использовать несколько локальных таблиц)

Все агенты опрашиваются параллельно. Список индексов передаётся удалённому агенту без изменений. Точный способ поиска по этому списку в агенте (последовательно или параллельно) зависит только от конфигурации агента (см. настройку threads). Мастер не управляет этим удалённо.

Важно отметить, что опция LIMIT игнорируется в запросах к агентам. Это связано с тем, что каждый агент может содержать разные таблицы, и ответственность за применение ограничения к итоговому набору результатов лежит на клиенте. Поэтому запрос к физической таблице отличается от запроса к распределённой таблице, если смотреть в логах запросов. Запрос не может быть простой копией исходного запроса, так как это приведёт к некорректным результатам.

Например, если клиент делает запрос SELECT ... LIMIT 10, 10, а существует два агента, при этом второй агент содержит только 10 документов, трансляция исходного запроса LIMIT 10, 10 приведёт к тому, что от второго агента будут получены 0 документов. Однако запрос LIMIT 10,10 должен вернуть документы с 10 по 20 из итогового набора. Чтобы решить эту проблему, запрос отправляют агентам с более широким ограничением, например, используя значение max_matches по умолчанию 1000.

Например, если есть распределённая таблица dist, которая ссылается на удалённую таблицу user, запрос клиента SELECT * FROM dist LIMIT 10,10 будет преобразован в запрос SELECT * FROM user LIMIT 0,1000 и отправлен удалённой таблице user. После получения результата распределённая таблица применит LIMIT 10,10 и вернёт запрашиваемые 10 документов.

SELECT * FROM dist LIMIT 10,10;

запрос будет преобразован в:

SELECT * FROM user LIMIT 0,1000

Кроме того, значение может содержать опции для каждого отдельного агента, такие как:

• ha_strategy - random, roundrobin, nodeads, noerrors (переопределяет глобальную настройку ha_strategy для конкретного агента)
• conn - pconn, persistent (эквивалентно установке agent_persistent на уровне таблицы)
• blackhole 0,1 (идентично настройке agent_blackhole для агента)
• retry_count целочисленное значение (соответствует agent_retry_count, но заданное значение не умножается на число зеркал)

agent = address1:table-list[[ha_strategy=value, conn=value, blackhole=value]]

Пример:

# config on box1
# sharding a table over 3 servers
agent = box2:9312:shard1
agent = box3:9312:shard2
# config on box2
# sharding a table over 3 servers
agent = box1:9312:shard2
agent = box3:9312:shard3
# config on box3
# sharding a table over 3 servers
agent = box1:9312:shard1
agent = box2:9312:shard3
# per agent options
agent = box1:9312:shard1[ha_strategy=nodeads]
agent = box2:9312:shard2[conn=pconn]
agent = box2:9312:shard2[conn=pconn,ha_strategy=nodeads]
agent = test:9312:any[blackhole=1]
agent = test:9312|box2:9312|box3:9312:any2[retry_count=2]
agent = test:9312|box2:9312:any2[retry_count=2,conn=pconn,ha_strategy=noerrors]

Для оптимальной производительности рекомендуется помещать удалённые таблицы, расположенные на одном сервере, в одну запись. Например, вместо:

agent = remote:9312:idx1
agent = remote:9312:idx2

следует предпочесть:

agent = remote:9312:idx1,idx2

agent_persistent = remotebox:9312:index2

Опция agent_persistent позволяет устанавливать постоянное соединение с агентом, то есть соединение не закрывается после выполнения запроса. Синтаксис этой директивы такой же, как у директивы agent. Однако вместо открытия нового соединения с агентом для каждого запроса и последующего его закрытия мастер будет поддерживать открытое соединение и повторно использовать его для последующих запросов. Максимальное количество постоянных соединений на хост агента задаётся опцией persistent_connections_limit в секции searchd.

Важно отметить, что значение persistent_connections_limit должно быть больше 0 для использования постоянных соединений с агентом. Если оно не определено, по умолчанию равно 0, и директива agent_persistent будет работать так же, как agent.

Использование постоянных соединений мастер-агент снижает нагрузку на TCP-порты и экономит время на установку соединений, делая процесс более эффективным.

agent_blackhole = testbox:9312:testindex1,testindex2

Директива agent_blackhole позволяет пересылать запросы к удалённым агентам без ожидания или обработки их ответов. Это полезно для отладки или тестирования продакшн-кластеров, так как можно настроить отдельный экземпляр для отладки/тестирования и пересылать запросы к нему с продакшн-мастера (агрегатора) без вмешательства в продакшн-работу. Мастер searchd будет пытаться подключиться к агенту-черной дыре и отправлять запросы как обычно, но не будет ждать и обрабатывать ответы, а все сетевые ошибки на агентах-черных дырах будут игнорироваться. Формат значения идентичен директиве agent.

agent_connect_timeout = 300

Директива agent_connect_timeout задает таймаут подключения к удалённым агентам. По умолчанию значение считается в миллисекундах, но может иметь другой суффикс). Значение по умолчанию — 1000 (1 секунда).

При подключении к удалённым агентам searchd будет ждать максимум это время, чтобы успешно установить соединение. Если таймаут достигнут, но соединение так и не установлено, и включены retries, будет выполнена попытка повторного подключения.

agent_query_timeout = 10000 # our query can be long, allow up to 10 sec

agent_query_timeout устанавливает время, в течение которого searchd будет ждать завершения запроса от удалённого агента. Значение по умолчанию — 3000 миллисекунд (3 секунды), но оно может иметь суффикс для указания другой единицы времени.

После установления соединения searchd будет ждать максимум agent_query_timeout для выполнения удалённых запросов. Обратите внимание, что этот таймаут отличается от agent_connect_timeout, и общая задержка, вызванная удалённым агентом, будет суммой обоих значений. Если время agent_query_timeout истечёт, запрос не будет повторяться, вместо этого будет выведено предупреждение.

Также поведение зависит от reset_network_timeout_on_packet

agent_retry_count — целое число, определяющее, сколько раз Manticore попытается подключиться и выполнить запрос удалённым агентам в распределённой таблице до сообщения о фатальной ошибке запроса. Работает аналогично agent_retry_count, заданному в разделе "searchd" конфигурационного файла, но применяется конкретно для таблицы.

mirror_retry_count выполняет ту же функцию, что и agent_retry_count. Если заданы оба значения, приоритет будет у mirror_retry_count, и будет выведено предупреждение.

Следующие параметры управляют общим поведением удалённых агентов и задаются в разделе searchd конфигурационного файла. Они устанавливают значения по умолчанию для всего экземпляра Manticore.

• agent_connect_timeout — значение по умолчанию для параметра agent_connect_timeout.
• agent_query_timeout — значение по умолчанию для параметра agent_query_timeout. Также может быть переопределено для каждого запроса с использованием того же имени параметра в распределённой (сетевой) таблице.
• agent_retry_count — целое число, указывающее, сколько раз Manticore будет пытаться подключаться и выполнять запросы удалённым агентам в распределённой таблице до сообщения о фатальной ошибке. Значение по умолчанию — 0 (т.е. без повторных попыток). Это значение также можно задать для каждого запроса с помощью опции 'OPTION retry_count=XXX'. Если задан параметр для отдельного запроса, он будет иметь приоритет над значением из конфига.

Обратите внимание, что при использовании зеркал агентов в определении распределённой таблицы сервер будет выбирать другое зеркало перед каждой попыткой подключения в соответствии с указанной ha_strategy. В этом случае agent_retry_count агрегируется для всех зеркал в наборе.

Например, если у вас есть 10 зеркал и установлено agent_retry_count=5, сервер сделает до 50 попыток (приблизительно 5 попыток на каждые 10 зеркал). В случае опции ha_strategy = roundrobin это будет ровно по 5 попыток на каждое зеркало.

При этом значение, заданное в опции retry_count в определении agent служит абсолютным лимитом. Другими словами, опция [retry_count=2] в определении агента означает максимум 2 попытки, независимо от того, сколько зеркал (1 или 10) в строке.

agent_retry_delay — целочисленное значение, определяющее время в миллисекундах, которое Manticore Search будет ждать перед повторной попыткой запросить удалённого агента в случае сбоя. Это значение можно указать глобально в конфигурации searchd или для каждого запроса с помощью директивы OPTION retry_delay=XXX. Если обе опции заданы, приоритет будет у параметра для отдельного запроса. Значение по умолчанию — 500 миллисекунд (0,5 секунды). Этот параметр актуален только если agent_retry_count или параметр OPTION retry_count для запроса больше нуля.

Опция client_timeout устанавливает максимальное время ожидания между запросами при использовании постоянных соединений. Значение задаётся в секундах или с суффиксом времени. Значение по умолчанию — 5 минут.

Пример:

client_timeout = 1h

Опция hostname_lookup определяет стратегию обновления имён хостов. По умолчанию IP-адреса host-имён агентов кешируются при запуске сервера, чтобы избежать чрезмерного обращения к DNS. Однако в некоторых случаях IP может динамически меняться (например, облачный хостинг), и может быть необходимо не кешировать IP. Установка этой опции в request отключает кеширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновлять вручную с помощью команды FLUSH HOSTNAMES.

Опция listen_tfo позволяет использовать флаг TCP_FASTOPEN для всех слушателей. По умолчанию она управляется системой, но может быть явно отключена, установив значение '0'.

Для получения дополнительной информации о расширении TCP Fast Open, пожалуйста, обратитесь к Wikipedia. Кратко, оно позволяет исключить один круг обмена TCP при установлении соединения.

На практике использование TFO может оптимизировать сетевую эффективность клиент-агента, аналогично использованию agent_persistent, но без удержания активных соединений и без ограничений на максимальное количество соединений.

Большинство современных операционных систем поддерживают TFO. Linux (как одна из самых прогрессивных) поддерживает его с 2011 года, начиная с ядра 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие системы, такие как FreeBSD и MacOS, также участвуют.

Для систем Linux сервер проверяет переменную /proc/sys/net/ipv4/tcp_fastopen и действует соответственно. Бит 0 управляет клиентской стороной, а бит 1 управляет слушателями. По умолчанию система имеет этот параметр, установленный в 1, то есть клиенты включены, а слушатели отключены.

persistent_connections_limit = 29 # assume that each host of agents has max_connections = 30 (or 29).

Опция persistent_connections_limit определяет максимальное количество одновременных постоянных соединений с удалёнными постоянными агентами. Это настройка на уровне экземпляра и должна быть определена в секции конфигурации searchd. Каждый раз при установлении соединения с агентом, определённым в agent_persistent, происходит попытка повторно использовать существующее соединение (если оно есть) или создать новое и сохранить его для будущего использования. Однако в некоторых случаях может потребоваться ограничить количество постоянных соединений. Эта директива задаёт лимит и влияет на количество соединений с каждым хостом агента для всех распределённых таблиц.

Рекомендуется установить это значение равным или меньшим, чем опция max_connections в конфигурации агента.

Особый случай распределённой таблицы — одна локальная и несколько удалённых, которая используется исключительно для создания распределённых сниппетов, когда сниппеты берутся из файлов. В этом случае локальная таблица может выступать в роли "шаблонной" таблицы, обеспечивая настройки для токенизации при построении сниппетов.

snippets_file_prefix = /mnt/common/server1/

Опция snippets_file_prefix — это необязательный префикс, который можно добавить к именам локальных файлов при генерации сниппетов. Значение по умолчанию — текущая рабочая папка.

Чтобы узнать больше о создании распределённых сниппетов, смотрите CALL SNIPPETS.

Вы можете создать распределённую таблицу из нескольких перколяционных таблиц. Синтаксис построения такого типа таблиц такой же, как и для других распределённых таблиц, и может включать несколько local таблиц, а также agents.

Для DPQ операции перечисления сохранённых запросов и поиска по ним (с использованием CALL PQ) прозрачны и работают так, как если бы все таблицы были одной локальной таблицей. Однако операции манипуляции данными, такие как insert, replace, truncate, отсутствуют.

Если в список агентов включить не перколяционную таблицу, поведение будет неопределённым. Если неправильный агент имеет ту же схему, что и внешняя схема PQ таблицы (id, query, tags, filters), это не вызовет ошибку при перечислении сохранённых правил PQ и может засорить список фактических правил PQ, хранящихся в PQ таблицах, собственными не-PQ строками. В результате будьте осторожны и понимаете путаницу, которую это может вызвать. Вызов CALL PQ к такому неправильному агенту вызовет ошибку.

Для получения дополнительной информации о выполнении запросов к распределённой перколяционной таблице смотрите выполнение запросов к распределённой перколяционной таблице.

Manticore Search имеет одноуровневую иерархию для таблиц.

В отличие от других СУБД, в Manticore нет концепции группировки таблиц в базы данных. Однако для совместимости с диалектами SQL, Manticore принимает операторы SHOW DATABASES для совместимости с диалектом SQL, но оператор не возвращает никаких результатов.

SHOW TABLES [ LIKE pattern ]

SHOW TABLES;

$client->nodes()->table();

utilsApi.sql('SHOW TABLES')

await utilsApi.sql('SHOW TABLES')

res = await utilsApi.sql('SHOW TABLES');

utilsApi.sql("SHOW TABLES", true)

utilsApi.Sql("SHOW TABLES", true)

utils_api.sql("SHOW TABLES", Some(true)).await

+----------+-------------+
| Index    | Type        |
+----------+-------------+
| dist     | distributed |
| plain    | local       |
| pq       | percolate   |
| rt       | rt          |
| template | template    |
+----------+-------------+
5 rows in set (0.00 sec)

Array
(
    [dist1] => distributed
    [rt] => rt
    [products] => rt
)

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'dist1', u'Type': u'distributed'},
           {u'Index': u'rt', u'Type': u'rt'},
           {u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'dist1', u'Type': u'distributed'},
           {u'Index': u'rt', u'Type': u'rt'},
           {u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{"columns":[{"Index":{"type":"string"}},{"Type":{"type":"string"}}],"data":[{"Index":"products","Type":"rt"}],"total":0,"error":"","warning":""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error=, warning=}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

SHOW TABLES LIKE 'pro%';

$client->nodes()->table(['body'=>['pattern'=>'pro%']]);

utilsApi.sql('SHOW TABLES LIKE \'pro%\'');

await utilsApi.sql('SHOW TABLES LIKE \'pro%\'');

utilsApi.sql('SHOW TABLES LIKE \'pro%\'')

utilsApi.sql("SHOW TABLES LIKE 'pro%'", true)

utilsApi.Sql("SHOW TABLES LIKE 'pro%'", true)

utils_api.sql("SHOW TABLES LIKE 'pro%'", Some(true)).await

+----------+-------------+
| Index    | Type        |
+----------+-------------+
| products | distributed |
+----------+-------------+
1 row in set (0.00 sec)

Array
(
    [products] => distributed
)

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{u'columns': [{u'Index': {u'type': u'string'}},
              {u'Type': {u'type': u'string'}}],
 u'data': [{u'Index': u'products', u'Type': u'rt'}],
 u'error': u'',
 u'total': 0,
 u'warning': u''}

{"columns":[{"Index":{"type":"string"}},{"Type":{"type":"string"}}],"data":[{"Index":"products","Type":"rt"}],"total":0,"error":"","warning":""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error=, warning=}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{columns=[{Index={type=string}}, {Type={type=string}}], data=[{Index=products, Type=rt}], total=0, error="", warning=""}

{DESC | DESCRIBE} table_name [ LIKE pattern ]

Оператор DESCRIBE выводит список столбцов таблицы и связанных с ними типов. Столбцы включают идентификатор документа, полнотекстовые поля и атрибуты. Порядок соответствует порядку, в котором поля и атрибуты ожидаются операторами INSERT и REPLACE. Типы столбцов включают field, integer, timestamp, ordinal, bool, float, bigint, string и mva. Столбец ID будет иметь тип bigint. Пример:

mysql> DESC rt;
+---------+---------+
| Field   | Type    |
+---------+---------+
| id      | bigint  |
| title   | field   |
| content | field   |
| gid     | integer |
+---------+---------+
4 rows in set (0.00 sec)

Поддерживается необязательное предложение LIKE. Подробности о его синтаксисе см. в разделе SHOW META.

select * from tbl.@table where type='text';

+------+-------+------+----------------+
| id   | field | type | properties     |
+------+-------+------+----------------+
|    2 | title | text | indexed stored |
+------+-------+------+----------------+
1 row in set (0.00 sec)

select field from tbl.@table;
select field, properties from tbl.@table where type in ('text', 'uint');
select * from tbl.@table where properties any ('stored');

SHOW CREATE TABLE table_name [ OPTION output_words = 'list' | 'file' ]

SHOW CREATE TABLE tbl\G

       Table: tbl
Create Table: CREATE TABLE tbl (
f text indexed stored
) charset_table='non_cont,cont' morphology='icu_chinese'
1 row in set (0.00 sec)

Если вы используете оператор DESC для перколяционной таблицы, он отобразит внешнюю схему таблицы, которая является схемой хранимых запросов. Эта схема статична и одинакова для всех локальных перколяционных таблиц:

mysql> DESC pq;
+---------+--------+
| Field   | Type   |
+---------+--------+
| id      | bigint |
| query   | string |
| tags    | string |
| filters | string |
+---------+--------+
4 rows in set (0.00 sec)

Если вы хотите просмотреть ожидаемую схему документа, используйте следующую команду: DESC <pq table name> table:

mysql> DESC pq TABLE;
+-------+--------+
| Field | Type   |
+-------+--------+
| id    | bigint |
| title | text   |
| gid   | uint   |
+-------+--------+
3 rows in set (0.00 sec)

Также поддерживается desc pq table like ..., и он работает следующим образом:

mysql> desc pq table like '%title%';
+-------+------+----------------+
| Field | Type | Properties     |
+-------+------+----------------+
| title | text | indexed stored |
+-------+------+----------------+
1 row in set (0.00 sec)

DROP TABLE products;

POST /cli -d "DROP TABLE products"

$params = [ 'table' => 'products' ];
$response = $client->indices()->drop($params);

utilsApi.sql('DROP TABLE products')

await utilsApi.sql('DROP TABLE products')

res = await utilsApi.sql('DROP TABLE products');

sqlresult = utilsApi.sql("DROP TABLE products", true);

sqlresult = utilsApi.Sql("DROP TABLE products", true);

let sqlresult = utils_api.sql("DROP TABLE products", Some(true)).await;

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''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

Синтаксис оператора DROP TABLE в SQL выглядит следующим образом:

DROP TABLE [IF EXISTS] table_name

DROP TABLE IF EXISTS products;

POST /cli -d "DROP TABLE IF EXISTS products"

$params =
[
  'table' => 'products',
  'body' => ['silent' => true]
];
$client->indices()->drop($params);

utilsApi.sql('DROP TABLE IF EXISTS products')

await utilsApi.sql('DROP TABLE IF EXISTS products')

res = await utilsApi.sql('DROP TABLE IF EXISTS products');

sqlresult = utilsApi.sql("DROP TABLE IF EXISTS products", true);

sqlresult = utilsApi.Sql("DROP TABLE IF EXISTS products", true);

let sqlresult = utils_api.sql("DROP TABLE IF EXISTS products", Some(true)).await;

{u'error': u'', u'total': 0, u'warning': u''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

TRUNCATE TABLE table_name [WITH RECONFIGURE]

TRUNCATE TABLE distributed_table

TRUNCATE TABLE products;

POST /cli -d "TRUNCATE TABLE products"

$params = [ 'table' => 'products' ];
$response = $client->indices()->truncate($params);

utilsApi.sql('TRUNCATE TABLE products')

await utilsApi.sql('TRUNCATE TABLE products')

res = await utilsApi.sql('TRUNCATE TABLE products');

utilsApi.sql("TRUNCATE TABLE products", true);

utilsApi.Sql("TRUNCATE TABLE products", true);

utils_api.sql("TRUNCATE TABLE products", Some(true)).await;

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''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}

{total=0, error="", warning=""}

Одно из возможных применений этой команды — перед присоединением таблицы.

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')

await utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE')

res = await utilsApi.sql('TRUNCATE TABLE products WITH RECONFIGURE');

utilsApi.sql("TRUNCATE TABLE products WITH RECONFIGURE", true);

utilsApi.Sql("TRUNCATE TABLE products WITH RECONFIGURE" ,true);

utils_api.sql("TRUNCATE TABLE products WITH RECONFIGURE", Some(true)).await;

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''}

{u'error': u'', u'total': 0, u'warning': u''}

{"total":0,"error":"","warning":""}

{total=0, error=, warning=}

{total=0, error="", warning=""}