What's the correct behavior for mongoDB when mongo hosts in two DC can't talk to each other Let's assume there are two data centers: DC1 and DC2.

In DC1:


Two mongodb hosts, one primary, one secondary. All mongo hosts in DC1 have the readPreferenceTag: dc:"DC1"
Two app host, the readPreferenceTag has set to dc:"DC1" within the mongo URI.


In DC2:


Two mongodb hosts, both set as secondary with priority 0 (can never be selected as primary). All mongo hosts in DC2 have the readPreferenceTag: dc:"DC2"
Two app host, the readPreferenceTag has set to dc:"DC2" within the mongo URI.


All Mongo hosts in both DCs are in one replica-set.

In normal workflow, app hosts in DC1 will W/R to DC1 mongo hosts and app hosts in DC2 will write to the primary mongo host in DC1 and read from mongo hosts in DC2.

My question is: If there's an network issue between the mongo hosts in DC1 and DC2 (mongo hosts in one DC will not be able to talk to the mongo hosts in the other DC but app hosts can still talk to mongo hosts in both DC), the app hosts in DC1 can still perform R/W operation with mongo hosts in DC1. 

But what's the correct behavior for the app hosts in DC2?

From the config status(rs.status()) in primary mongo host we can know that all mongo hosts in DC2 will be in 'unreachable' state, so will app hosts in DC2 still read from DC2 mongo hosts or they will read from DC1 mongo hosts instead?
In this strange situation where somehow mongod processes are network partitioned (between DC's) but application nodes are not. DC2's mongod nodes stays on "SECONDARY" status.

So, YES, DC2 applications still keep reading from DC2 mongod nodes even if data is not updated from primary.

BUT, in this layout your PRIMARY (at DC1) won't stay as primary if there is network partition between DC1 and DC2, because you have four voting nodes and after loosing two votes (DC2) there is no majority. 

You need arbiter and it should be located at DC3. There should never be 'even' vote count in replica set.