Jeśli wszystkie instancje znajdują się za jednym Input ze zrównoważonym obciążeniem punkt końcowy (np. 27017), wtedy za każdym razem, gdy komputer kliencki łączy się z punktem końcowym, zostanie on połączony z potencjalnie różnymi węzłami w klastrze zestawu replik (i nie będziesz mieć kontroli nad tym, do którego wystąpienia przeszedłeś). To może wyjaśniać, dlaczego czasami próbujesz pisać do serwera innego niż główny i otrzymujesz błąd, ale wszystkie odczyty działają (ponieważ prawdopodobnie skonfigurowałeś klaster MongoDB, aby zezwalał na odczyty na węzłach drugorzędnych).
Role pracowników obsługują również InstanceInput punkty końcowe, które pozwalają ustawić zakres portów skierowanych zewnętrznie (np. 27017-27019), mapujący do pojedynczego portu w samych instancjach roboczych (np. 27017). Jeśli to zrobisz, Twoja aplikacja kliencka może teraz łączyć się bezpośrednio ze wszystkimi trzema instancjami (27017, 27018, 27019). Wiele sterowników obsługuje połączenia z zestawami replik, dzięki czemu będzie w stanie określić, który węzeł jest nadrzędny, kierując do niego wszystkie zapisy. Nie wiem, czy sterownik, którego używasz w systemie Android, obsługuje zestawy replik. Jeśli sterownik nie obsługuje zestawów replik, prawdopodobnie zechcesz rozważyć utworzenie warstwy interfejsu API, która następnie prowadzi całą komunikację z bazą danych (w każdym razie ogólnie należy postępować zgodnie z dobrą praktyką, a możesz sprawdzić usługi mobilne platformy Azure dla szybki sposób na zaimplementowanie tego).
A więc... jeśli punkt końcowy klastra zestawu replik jest skonfigurowany jako Input , prawdopodobnie wyjaśnia to napotkany problem, który powinien być rozwiązany przez przełączenie typu punktu końcowego na InstanceInput .
