Hvis instanserne alle sidder bag en enkelt belastningsbalanceret Input endepunkt (f.eks. 27017), og hver gang din klientmaskine opretter forbindelse til endepunktet, vil den blive forbundet til potentielt forskellige noder i replikasæt-klyngen (og du ville ikke have nogen kontrol over, hvilken instans du gik til). Dette kan måske forklare, hvorfor du nogle gange forsøger at skrive til ikke-masteren og får en fejl, men alligevel fungerer alle dine læsninger (da du sandsynligvis har konfigureret MongoDB-klyngen til at tillade læsninger på sekundære noder).
Arbejderroller understøtter også InstanceInput endepunkter, som giver dig mulighed for at indstille et eksternt vendt portområde (f.eks. 27017-27019), der tilknyttes en enkelt port på selve arbejderforekomsterne (f.eks. 27017). Hvis du gør dette, kan din klientapp nu oprette forbindelse til alle tre forekomster direkte (27017, 27018, 27019). Mange drivere understøtter replikasætforbindelser, så det ville være i stand til at finde ud af, hvilken node der er masteren, og dirigere alle skrivninger til den. Jeg ved ikke, om den driver, du bruger på Android, understøtter replikasæt. Hvis driveren ikke understøtter replikasæt, vil du sandsynligvis overveje at oprette et API-niveau, som derefter udfører al kommunikation til databasen (en god praksis at følge generelt, i hvert fald, og du kan se på Azures Mobile Services for en hurtig måde at implementere dette på).
Så... hvis din replikasæt-klynges slutpunkt er konfigureret som Input , dette forklarer sandsynligvis det problem, du ser, som burde kunne løses ved at skifte slutpunktstypen til InstanceInput .