I need fault tolerance 2 and I don't want use extra server for that. I plan use following configuration for each replica sets. Each mongodbX-X is different server.
DC1 (main):
mongodb0-0 - primary
mongodb0-1 - secondary
DC2:
mongodb0-2 - secondary, priority 0.5
mongodb0-3 - arbiter
mongodb0-4 - arbiter
Is it correct? I can't find any discussion about same configuration.
It is true that failure of up to 2 members should still leave a voting majority to elect a primary in a 5-member replica set, however there are a few other factors to consider.
The number of data-bearing members available in your replica also affects the Write Concerns that can be acknowledged.
For example, with your configuration of two arbiters any data-bearing member being down means that a w:majority write concern cannot be satisfied. There may be administrative reasons for a member to be offline (for example, if you are running a repair or perhaps building indexes on a secondary) so the highest write concern you can safely use without impacting your application availability is going to be w:2.
If for some reason two data-bearing members fail, you will only be able to satisfy a single node acknowledged write. There is no longer any replication until at least one other data-bearing member rejoins the replica set.
You may have no issues with your actual replica set members, but if connectivity between DC1 and DC2 is lost only DC2 has enough voting members to elect a primary. The danger here is that DC2 only has a single secondary in your configuration, so at this point you technically have no members down but a single member failure (of the only data-bearing member in DC2) can cause data loss.
Since the arbiters aren't under any write load, the data-bearing members are the ones most likely to fail or require maintenance. Adding two arbiters gives you the appearance of more fault tolerance, but with the caveats as noted above.
A more robust recommendation would be to have:
DC1: primary, secondary (priority: 2)
DC2: secondary, secondary (default priority)
DC3: arbiter
In this configuration any two data-bearing members can fail or you can lose connection for a whole data centre, and still have a primary as well as ongoing replication. The higher priority on the DC1 members prefers those as candidates for the replica primary (assuming they are available and up to date).
If you don't want to have three secondaries, a more minimal configuration which gives you similar failover benefits (although only a single node of fault tolerance) would be:
DC1: primary (priority 3)
DC2: secondary (priority 2)
DC3: secondary (default priority)
This allows for failover to either DC1 or DC2 with continued replication, and also maintains the semantics of majority write concern matching a majority of the replica set members being available.