Elasticsearch Indexing Jobs in Sugar 7

RE: Elasticsearch Indexing Jobs in Sugar 7

SugarCRM Developers — Fri, 21 Jul 2017 14:09:33 GMT

Comment originally made by Kat.

Hi Matt,

I have two instances of sugarcrm that is on HA. I tried system index on the first server then on the second server but it seems that ES is only using one server. I also tried to change the unique_key in the config.php. I also setup unique cluster.name and node.name for each servers.

Is there a possible to setup ES on both servers so that when the other server went down, it won't depend on the other server.

By the way, ES is installed by each server.

Thanks

RE: Elasticsearch Indexing Jobs in Sugar 7

SugarCRM Developers — Thu, 13 Oct 2016 23:10:50 GMT

Comment originally made by Marc.

thanks for the useful article. Which make the word a better place :)

However, i have 2 questions:

After active a full re-indexing for a quite long time, i noticed that in the job_queue table, the job "FTSConsumer Accounts" has been marked as "done" and "success", however, in the fts_queue table, there are still quite a lot accounts records left there with "processed" equals 0. Then i found those are the records that had been deleted(=1). My question is, what is sugar's intention? If those are not suppose to be indexed, which i believe so, why not exclude those from put into fts_queue table at the first place?

Another question is about "$sugar_config['cron']['max_cron_jobs'] = 500;". When you say add it "deploy/automation", did you mean the live environment?

RE: Elasticsearch Indexing Jobs in Sugar 7

SugarCRM Developers — Mon, 14 Sep 2015 21:31:19 GMT

Comment originally made by TamW.

Thanks for this useful article. We really struggle with no easy way for Administrators to see what's in the fts_queue table after a re-index, i.e. no visual way to know that the re-index has finished successfully. Calling on our db team to check progress frequently is not ideal. We also found that when the job for each module hits a timeout it doesn't restart or seem to even make use of the retry columns in the job queue table. We had to make db changes to restart the jobs. Admittedly some of the tables we index are huge. Combined with the fact that the full re-index job starts by clearing all the ETS index information, we've been badly caught out when when the re-indexing stops part way through ... and the global search stops working for our users! We've created our own scheduled task which does not clear the already indexed data. Would also be keen to know how to create a scheduled task that allows passing through extra parameters so that we can make one where the administrator can specify a specific module to re-index. We run more than one ETS server and while the config.php file takes multiple servers the Admin UI breaks that config. So we look forward to any improvements in the ETS indexing :-) BTW ... our users love the global search! (although now they want us to customise the displayed results to better match their Account groupings, e.g. by region)