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 :
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}
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.
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....
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.
Oui on s'y perd un peu
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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.