Si les instances sont toutes assises derrière une seule Input à charge équilibrée point de terminaison (par exemple 27017), chaque fois que votre machine cliente se connecte au point de terminaison, elle sera connectée à des nœuds potentiellement différents dans le cluster de réplicas (et vous n'aurez aucun contrôle sur l'instance à laquelle vous êtes allé). Cela peut expliquer pourquoi vous essayez parfois d'écrire sur le non-maître et obtenez une erreur, mais toutes vos lectures fonctionnent (puisque vous avez probablement configuré le cluster MongoDB pour autoriser les lectures sur les nœuds secondaires).
Les rôles de travail prennent également en charge InstanceInput points de terminaison, qui vous permettent de définir une plage de ports orientés vers l'extérieur (par exemple, 27017-27019), mappée à un seul port sur les instances de travail elles-mêmes (par exemple, 27017). Si vous procédez ainsi, votre application cliente peut désormais se connecter directement aux trois instances (27017, 27018, 27019). De nombreux pilotes prennent en charge les connexions de jeu de répliques, il serait donc en mesure de déterminer quel nœud est le maître, en y dirigeant toutes les écritures. Je ne sais pas si le pilote que vous utilisez sur Android prend en charge les jeux de répliques. Si le pilote ne prend pas en charge les jeux de réplicas, vous voudrez probablement envisager de mettre en place un niveau d'API qui effectue ensuite toutes les communications avec la base de données (une bonne pratique à suivre en général, de toute façon, et vous pouvez consulter les services mobiles d'Azure pour un moyen rapide de mettre cela en œuvre).
Donc... si le point de terminaison de votre cluster de réplicas est configuré en tant que Input , cela explique probablement le problème que vous rencontrez, qui devrait être résolu en basculant le type de point de terminaison sur InstanceInput .
