Pokud všechny instance sedí za jediným Input s vyváženým zatížením koncový bod (např. 27017), pak pokaždé, když se váš klientský počítač připojí ke koncovému bodu, bude připojen k potenciálně odlišným uzlům v clusteru replik (a nebudete mít žádnou kontrolu nad tím, do které instance jste přešli). To by mohlo vysvětlovat, proč se někdy pokoušíte zapisovat do non-master a dostanete chybu, přesto všechna vaše čtení fungují (protože jste pravděpodobně nastavili cluster MongoDB tak, aby umožňoval čtení na sekundárních uzlech).
Pracovní role také podporují InstanceInput koncové body, které umožňují nastavit rozsah portů směřujících zvenčí (řekněme 27017-27019), mapování na jeden port na samotných pracovních instancích (např. 27017). Pokud to uděláte, vaše klientská aplikace se nyní může připojit ke všem třem instancím přímo (27017, 27018, 27019). Mnoho ovladačů podporuje připojení replikaset, takže by bylo možné zjistit, který uzel je hlavní, a směrovat všechny zápisy na něj. Nevím, zda ovladač, který používáte v systému Android, podporuje replikace. Pokud ovladač nepodporuje replikacety, pak pravděpodobně budete chtít zvážit vytvoření vrstvy API, která pak provádí veškerou komunikaci s databází (obecně je to dobrý postup, můžete se podívat na mobilní služby Azure. rychlý způsob, jak to implementovat).
Takže... pokud je koncový bod vašeho replikačního clusteru nakonfigurován jako Input , to pravděpodobně vysvětluje problém, který vidíte a který by měl být řešitelný přepnutím typu koncového bodu na InstanceInput .