1

Context

  • I am trying to design a stable, consistent approach to updating RavenDB indexes in production
  • I am focusing specifically on the index update story (i.e. I know my setup doesn't fully address high availability)
  • This is a hypothetical scenario (i.e. there is nothing currently in production)
  • Assume hardware/software/network configurations are flexible (i.e. adding another RavenDB instance, more servers, persistent cache, etc.)

Current hosting scenario

  • 2x web servers load balanced in active-passive configuration, each running 1 web application
  • 1x server running RavenDB instance (latest stable version)

Constraints

  • High-availability must be maintained throughout the whole process
  • The deployment process will be completely automated
  • The deployment process may initiate a rollback at any point throughout the deployment
  • Index rebuild may take up to 1 minute; and it is not acceptable to not have data available for display this long

Potential solution

Add a second RavenDB instance and replicate RavenDB in active-active configuration

  • Active web server talks to active RavenDB instance
  • Passive web server talks to passive RavenDB instance

Deployment would look like this:

  • Stop replication
  • Deploy new web application code to passive web server
  • Start web application and let it auto-update index definitions in its RavenDB instance
  • Test
  • Switch load balancer to passive web server, making it active
  • Monitor (for x amount of time) and rollback if needed
  • Start replication and let index definitions and data update in the other RavenDB instance

Rollback would look like this:

  • Switch load balancer to passive web server, making it active

Is there a more optimal way to implement this?

Arnold Zokas
  • 8,306
  • 6
  • 50
  • 76

1 Answers1

0

We accomplish something similar by storing the index names in a configuration variable. Then we create a new index with the updated definition under a new name. Once it is finished, we switch the configuration variable to point to the new index name.

Depending on your process, you can hard-code index names in your separate builds, make this setup and switch part of your startup code, or any number of alternatives for whatever works best for you.

This process should work fine as long as the index definition outputs aren't radically different. If they are, you may need more controls with which web server is using which definition.

Jon Adams
  • 24,464
  • 18
  • 82
  • 120