Sql-server – Fastest way to migrate database to AlwaysOn cluster

availability-groupsmigrationsql server

I want to make the fastest migration plan to move a SQL Server database in simple recovery from a standalone server (SQL 2005) to a two node AlwaysOn cluster in full recovery.

Some databases are larger than 200gb so restore them in primary node, switch to full mode and add them to AlwaysOn by selecting full in initial data synchronization is not an option because that would make another backup/restore, taking a lot of time and resources (Time is critical!).

What I want is to restore the database in parallel in all the nodes at the same time (using norecovery I think? ) and then join them to the AlwaysOn group.
I have already read the documentation about AlwaysOn and it's not clear about this.

Would it be ok if I follow these steps:

  1. In Standalone server: Set database to single user mode, switch
    database to full recovery
  2. Backup database from standalone server and restore it in primary
    node with recovery and restore it in secondary node with no recovery
  3. Add database to AvailabilityGroup by selecting "Join only" in
    Initial Data Synchronization

Extra info:

  • The standalone server is 2005 standard, so it's not possible to
    join it as a new node.
  • I want to make as less backup/restore as possible.
  • What I meant with set the database to single user is that there will be no changes in the database during the migration. It's important because I could make a full backup and then I wont need a differential backup.

Questions:

  • After restoring database in Primary node and Secondary node: if I want to join the database to an AG Do I also need to make log backup/restore even though the database had
    just change to full recovery and no one but me has connected to it?
  • Wich option should I choose in Select Initial Data Synchronization
    Page on the AG Wizard ? Join Only or Skip data synchronization?

Thanks!

Best Answer

The fastest way would be to create a cluster an join your current stand alone server to the cluster as a new node. Set the database to full recovery model, take a full backup and a transaction log backup and restore them to the instance on the other node with norecovery.

If you have a good full backup (most recent), it would be possible to set the recovery model to full, take a differential and then take a log backup using the last full from the simple recovery model as your base. The differential should bridge the lsn gap.

To answer your questions:

  1. I'm not sure why you're switching the database into single_user except that you want no changes to be made. If you add the server as a node as I've set forth, this won't be an issue. Otherwise, yes, you'll need downtime to migrate the database. Your other option would be to set the recovery model to full, get it in full, setup mirroring to the new instance on the cluster and then cut over during a downtime which would be much less time.

  2. That's entirely possible to do, but in your initial question you said you didn't want to do this.

  3. You must restore at least one log or differential to bring the lsn gap as close as possible.

  4. I would not use the wizard, but the join only means you've staged a database that is currently in norecovery and it only needs to join the AOAG. The wizard will want to pre-stage the databases for you and ask you for shared locations, etc. Like I said it's best to pre-stage and not use the wizard for the best flexibility.

Related Question