Number of replicas automatically reset to 1

Est-ce que quelqu'un qui utilise PHP devant Elasticsearch pourrait m'aiguiller sur le debug de mon script ? Comme le précise dadonnet :

Ca veut dire que tu détruis l'index à chaque run et que tu le reconstruis.

Mais impossible de comprendre comment j'arrive à ce résultat ...

D'avance merci :wink:

Cette ligne ?

$response = $this->elastic->indices()->delete($params);

Je l'ai commentée pour essayer. A la base, le but était qu'à chaque initialisation, on repart à zéro et on reconstruis tout. Toujours pas d'affichage cependant.
Voilà où j'utilise les fonctions citées precedemment :

public function elasticAddAction(){
        $annonces = $this->annonceTable->fetchAnnoncesPropose();

        $i = 0;

        $this->searchService->init();
        foreach($annonces as $annonce){
            $city = $this->villeTable->getVille($annonce->id_ville);
            $coordinates = $this->searchService->get_coordinates($annonce->adresse.', '.$annonce->nom_ville,$city->cp);

            if($coordinates !== false){
                $this->searchService->reset_conn();

                $url_provider = $this->urlProvider;
                $url = $url_provider(null, $annonce->id_membre, $annonce, false, true, null, '#form-search-global');

                $result = $this->searchService->add_annonce($annonce, $coordinates['lat'],$coordinates['long'], $url);

                var_dump($result);

                //break;
                //break;
                if($i==15){
                    //break;
                }
                $i++;
            }
            else{
                var_dump($annonces);
                var_dump(urlencode($annonce->adresse.' '.$annonce->nom_ville));
            }
            sleep(1.5);
        }

        echo 'FIn ajout';

    }

Par ailleurs j'ajoute l'erreur obtenue la plus récente :

The application has thrown an exception!
======================================================================
Elasticsearch\Common\Exceptions\Missing404Exception
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","index_uuid":"fsA12HldQsGUgxEBjA--Wg","index":"coloc"}],"type":"index_not_found_exception","reason":"no such index","index_uuid":"fsA12HldQsGUgxEBjA--Wg","index":"coloc"},"status":404}

A la base, le but était qu'à chaque initialisation, on repart à zéro et on reconstruis tout.

Ben alors c'est bon. Pourquoi penses-tu que le fait de changer d'ID d'index est un problème ?

Le problème c'est que si je lance mon script actuellement, j'obtiens l'erreur citée ci-dessus. Qui plus est, le fait de changer ID de l'index ne me dérange pas. C'est même ce que j'attends lorsque je lance mon script. Ce qui me dérange, c'est que l'ID change même pendant l'execution de mon script. Il n'est censé changer l'ID qu'une seule fois lorsque je lance mon script. Je ne récupère aucune données.... Le script ne fait que créer l'index, le détruire, le créer, le détruire etc.... Il ne fait jamais passer mes données dessus...

Le script ne fait que créer l'index, le détruire, le créer, le détruire

C'est très confus pour moi ce que tu fais ou ce que tu veux faire.
Pourrais-tu exprimer cela avec un script qu'on peut exécuter dans la console Kibana.

Un exemple complet dans ce message: About the Elasticsearch category

Alors, je vais faire ce que tu m'as précédemment demandé mais avant je te mets ici la sortie que j'ai eu sans avoir lancer mon script.

[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc t0xzoUuyTSyJ83Dezne8zw   5   1          0            0      1.1kb          1.1kb
[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc _hztDe_9TAeGLDvd8KBK5w   5   1          0            0      1.1kb          1.1kb
[root@stock /]#

Entre la première commande et la deuxième, j'ai laissé passé 15min et l'UUID de l'index coloc a changé... Seul, sans intervention quelconque....

Il y a obligatoirement un bout de code qui tourne quelque part et qui détruit l'index et le créé à nouveau.

Essaye de faire ceci:

DELETE coloc
PUT coloc
PUT coloc/_doc/1
{ "foo":"bar" }
GET _cat/indices?v

Attends 15 minutes puis:

GET _cat/indices?v

Et poste le résultat de chaque requête ici.

Je n'arrive même pas à ajouter le doc. J'ai pourtant désactivé mon script. J'ai fait ces tests directement sur le serveur.

[root@stock /]# curl -XPUT localhost:9200/coloc/_doc/1
{"error":{"root_cause":[{"type":"parse_exception","reason":"request body is required"}],"type":"parse_exception","reason":"request body is required"},"status":400}[root@stock /]#

Voilà tout de même le _cat. On voit bien qu'il y a suppression de l'indice et création à nouveau. Malgré que le fait que j'ai viré mon script et que RIEN n'utilise ElasticSearch pour le moment.

[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc bj3zgV8iR9CXSLyCy8xMMg   5   1          0            0      1.1kb          1.1kb
[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc KDyqY-pxSr29VVYVmPnajQ   5   1          0            0      1.1kb          1.1kb
[root@stock /]#

J'ai modifié mon script. Il manquait quelque chose.

En tout cas, elasticsearch n'efface jamais des index utilisateur tout seul.
Je n'ai toujours pas une vision claire de ce que tu fais exactement. Comment tu lances le script, elasticsearch...?

C'est une tâche automatisée. Tous les jours à minuit, le script PHP détruit l'index 'coloc', le recréé et le remplit avec les données provenant d'une BDD mySQL. Le nouvel index 'coloc' est donc utilisé dans la journée et mis à jour tous les soirs à minuit. A la fin du processus (une fois que l'index contient tous mes documents) le script s'arrête et attend minuit pour recommencer.

Donc ton script DETRUIT bien l'index, non ?

Je suis perdu honnêtement dans ce thread. Je ne sais même plus ce qu'on essaye de résoudre.

Peux-tu résumer rapidement quel est le problème ?

Oui on s'y perd un peu :wink:
Petit résumé. J'utilise ElasticSearch pour passer en revue ma base de données mySql et stocker certaines données sur l'index 'coloc' d'eslasticsearch. Pour cela, un script passe tous les jours à minuit pour mettre à jour ElasticSearch puis se termine (en environ 30min).
Un petit résumé rapide par fonction de mon script php :

creationDuClient()
{
Je construis ici simplement le client
} 

initialisation()
{
Je vérifie si l'index 'coloc' existe. 
Si oui, je le détruis et le recréé avec le bon mapping.
Si non, je le créé tout simplement avec le bon mapping. 
}

ajoutDesDonnées()
{
Ici, je récupère les infos contenues dans ma bdd MySql et je les ajoute à mon index 'coloc' elasticsearch.
}

Je rappelle que le script ne s'execute qu'une fois par jour.

Le problème : même quand le script ne tourne pas, l'index 'coloc' sur ElasticSearch passe son temps à être détruit puis reconstruit etc..etc...

Tous les processus liés à mon script sont 'kill', l'index 'coloc' devrait donc simplement rester dans son état actuel sans rien changer.

Le problème : même quand le script ne tourne pas, l'index 'coloc' sur Elasticsearch passe son temps à être détruit puis reconstruit etc..etc...

Cela n'est pas possible. Il y a obligatoirement quelque chose qui tourne, qui efface éventuellement le répertoire data...

Hello!
Enfin, j'ai trouvé pourquoi l'index se détruisait et recréait continuellement. J'avais une vieille instance ElasticSearch version 5 planquée sur le serveur.
Résultat, je récupère maintenant tous mes docs sans problèmes et l'UUID ne change plus

[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc VuR8e4baQFa7ngKynboJeA   5   1       1553            0      2.1mb          2.1mb
[root@stock /]# curl localhost:9200/_cat/indices?v
health status index uuid                   pri rep docs.count docs.deleted store.size pri.store.size
yellow open   coloc VuR8e4baQFa7ngKynboJeA   5   1       1649            0      2.7mb          2.7mb
[root@stock /]#

C'est encore en train de récupérer les documents et je n'ai pas encore testé si j'avais mon affichage derrière, je vous tiendrai au courant.

Tout fonctionne. Ce fut long et douloureux mais je te remercie pour ton aide et les pistes que tu m'as apportées. dadoonnet.

Au plaisir de revenir poser des questions tordues sur le forum :wink:

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.