Somewhat counter-intuitive, this behavior is set at the client level, not the server. When servers are setup for replication, they create system documents of the other servers involved in replication. When the client accesses the primary server, it downloads and caches the replication information, so the client can “fail over” properly. To set this up, you need to assign the FailoverBehavior convention in your DocumentStore. Here is how we’re doing it with Ninject:

// RavenDB Services
Bind().ToMethod(context =>
{
  // Create the DocumentStore (expensive operation).
  var documentStore = new DocumentStore
  {
    ConnectionStringName = "RavenDB",
    // For "trusted connections": see comments at
    // http://ravendb.net/docs/client-api/connecting-to-a-ravendb-datastore
    Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
  };
  // When connecting to the primary database, the RavenDB client will learn
  // of any other servers used in replication. The following tells the client
  // that it can read and write to all servers.
  documentStore.Conventions.FailoverBehavior = FailoverBehavior.ReadFromAllServers
      | FailoverBehavior.AllowReadsFromSecondariesAndWritesToSecondaries;
  // Initialize the store and return it.
  return documentStore.Initialize();
}).InSingletonScope();

By default, all servers will have read access, but only the primary database can be written to. NOTE: If you have Master-to-Master replication configured, there is a small chance you’ll have to deal with conflicts.

References

Client Integration Master-to-Master replication Transitive Replication FailoverBehavior options and Load Balancing Windows Clustering Load balancing and efficient data reading when replication is available