Error occurs when using max_matches

General Discussions - English
#1

We have two nodes in cluster. After creating a cluster and adding empty indexes to it, everything works well. However, after one index is filled, we get the following error:

mysql> SELECT un_sku_id FROM sku OPTION max_matches = 1;
ERROR 1064 (42000): unknown option ‘max_matches’ (or bad argument type)

The error occurs only on the first node. The second node returns proper results for this query. It happens when using version 3.5.2. With version 3.5.0 everything works properly.

#2

Can you make a step-by-step scenario that reproduces this and open a ticket on github? I just tried on our replication course (https://play.manticoresearch.com/replication/) and I can’t reproduce it.

#3

Unfortunately, the only way to reproduce it is to provide you SQL dump with ~400.000 insert queries, but this is sensitive data. We have no idea after which of these queries the problem occurs. The only thing we know is that the problem is not reproduced on an empty index.

It’s OK for us to stay at 3.5.0, if there is no other way to investigate the issue.

#4

could you provide output of desc sku and show index sku status commands after error happens?

#5

If you have debugger onboard and installed debug symbols package for release, you can provide backtrace to us.
That is most probably from searchdsql.cpp line 532. If you set breakpoint there (after attaching to running instance with gdb), and then reproduce the error (so that breakpoint will be hit), you can issue command ‘where’ and attach the output (of course, you can check if that output doesn’t contains your sensitive data).

#6

Unfortunately, we do not have the ability to provide this information at the moment as long as we downgraded to version 3.5.0. If we upgrade Manticore in the future and experience the same problem, we will provide you with the necessary information then.

Thank you!

#7

Ok, we have experienced the problem again with Server version: 3.5.3 c419a324@201105 release git branch HEAD (no branch).

image
image1123×624 83.1 KB

Index config is here: https://pastebin.com/raw/BjQGRk8v

#8

I build daemon from master branch Manticore 3.5.3 c419a3248@201105 dev and all works well

mysql -h 127.0.0.1 -P 8306 -vv -e "select grls_id from grls LIMIT 0,50 OPTION max_matches = 50;"                                                     --------------                                                                                                                                                                                  select grls_id from grls LIMIT 0,50 OPTION max_matches = 50                                                                                                                                     --------------                                                                                                                                                                                                                                                                                                                                                                                  Empty set (0.00 sec)

could you provide complete example that recreates issue locally?
could you use binary from dev repo that got built by our CI?

#9

I’m not sure in which moment the problem occurs. When indexes are created from scratch and added to cluster, everything works well. The problem occurs suddenly when indexes are filling.

We use the same binary as you mentioned.

The problem does not occur with version 3.5.0. Only with 3.5.2 and higher.

#10

could you try suggestion from Alexey and provide that information?

#11

We can try, if you provide step-by-step instructions on how to achieve this.

#12

Could you assist please?

#13

there was a fix at dc7285890c8816d53b19f791c25f37bce4eac1f1 of reduce \ shift at SphinxQL parser at option - could you try to use recent dev version of daemon and post here what package will you use?

I will provide step by step debug instruction for that package as GDB commands will use source code line numbers.

#14

It seems that the fix has helped! The error has gone.

Thank you! I will let you know if something goes wrong.

#15

I have managed to reproduce the problem at Server version: 3.5.3 4367c82a@201116 release git branch HEAD (no branch). There were the following steps:

  1. I created 12 RT indexes on a server, created a cluster and added these indexes to the cluster.
  2. I added two additional nodes to the cluster.
  3. Then I filled all indexes in the cluster.
  4. After this I stopped Manticore on the 3rd node and cleaned data and binlog folders. Then I restarted the server.
  5. After the server is restarted, I joined the 3rd node to the cluster again (as long as it became a vanilla Manticore instance with no indexes).
  6. The node joined to the cluster properly, however the problem appeared again on this node. On the 1st and 2nd nodes the problem is not reproduce, the query is executed without any errors there.
#16

Can you please create an issue about this on github with detailed steps to reproduce it?

#17