Gestion de l'index Zend_Search_Lucene dans un environnement à charge équilibrée

Question

Chaque serveur du cluster dispose d'un index de recherche synchronisé à partir de l'un des serveurs toutes les 15 minutes. Cela a été fait parce que l'ajout à un index ne peut pas arriver sur un nfs à cause du troupeau; voir documentation (ou sinon l'index serait sur un dossier partagé auquel tous les serveurs accèdent). Le problème que je rencontre est que si une action nécessitant une modification de l'index est effectuée, les modifications se produisent sur la copie locale de l'index et j'ai besoin d'un moyen de synchroniser ces modifications avec le parent. la manière la moins intrusive possible (afin que les changements se propagent à tous les serveurs du cluster par la prochaine synchronisation).

J'ai essayé de référencer l'index du serveur parent via http, mais cela ne fonctionnera pas car mkdir ne peut pas être effectué via http. Existe-t-il un moyen de référencer l'index d'un serveur distant? Si une approche totalement différente est envisagée, elle sera également prise en compte

Answer 1

Si je comprends bien cette situation, si l'un des index du serveur subit une modification, vous voulez que l'index principal comme source de rsynch reçoive la mise à jour avant la suivante rsync a lieu - pour mettre à jour tous les serveurs avec la mise à jour. Au lieu de rsync -ing l'index du serveur principal, pourquoi rsync prend-il la dernière date de modification comme source pour le rsync? Donc, si la dernière mise à jour de l'index sur le serveur D est supérieure à l'index sur le serveur principal A, synchronisez simplement tous les serveurs sur la source de D

Ai-je bien compris votre situation?

Modifier

Ensuite, dans ce cas, modifier le code qui construit l'index es et ajouter une ligne qui vérifie si la version précédente de l'indice était différent, le cas échéant lancer un appel exec à une coquille script ou créez la commande manuellement pour mettre à jour le serveur central. De cette façon, le serveur central recevra des mises à jour à la volée et lorsque la grande synchronisation sera désactivée, votre problème sera résolu.

Answer 2

La meilleure solution à laquelle je puisse penser est de suivre un modèle de réplication Maître/Esclave plus traditionnel. Inspirez-vous de la réplication RDBMS: Toutes les écritures doivent aller au maître.

Bien sûr, vous ne pouvez pas le faire directement. Comme vous l'avez mentionné, vous ne pouvez pas écrire directement dans l'index distant. Donc, cela vous laisse une option: Exposez une API/Service sur votre serveur maître que les esclaves peuvent utiliser pour mettre à jour indirectement l'index. Ensuite, tous les changements seront synchronisés lors de votre prochaine poussée programmée. Je réalise que ceci peut être un changement significatif à votre conception, mais dans un environnement répliqué ou distribué, ceci est souvent nécessaire.