{"id":36399,"date":"2019-08-22T05:08:17","date_gmt":"2019-08-22T12:08:17","guid":{"rendered":"https:\/\/virtual-dba.com\/?p=36399"},"modified":"2023-08-11T07:51:13","modified_gmt":"2023-08-11T14:51:13","slug":"migrating-your-alwayson-dr-node-to-a-different-location","status":"publish","type":"post","link":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/","title":{"rendered":"Migrating Your AlwaysOn DR Node to a Different Location"},"content":{"rendered":"\n<p>There may be a situation when you need to move one of your servers that is part of an Availability Group to a different data center and the IP address for that server will change. In this example, we will be moving a DR node from one data center to another and change the IP of that server. I will not talk about how to VMotion (VMWare) the server to a different data center. Nor will I mention how to change the IP address within DNS and on the server itself. That is out of the scope of this blog.<\/p>\n\n\n\n<p>Follow these steps to remove the DR node from the AG and Cluster since it will get a new IP address and be located on a different subnet. For servers that are on different subnets, you have to have a cluster IP and listener IP for each subnet. You may have a situation where you have two nodes in the same subnet and one DR or another secondary server in a different subnet. In that scenario, you will have one cluster IP address and one listener IP address for each subnet so a total of two cluster and two listener IP addresses. You may also have a scenario where all three of your servers are in different subnets. In that case, you will have three cluster IP addresses and three listener IP addresses total.<\/p>\n\n\n\n<p>Example of IPs:<\/p>\n\n\n\n<figure class=\"wp-block-image is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/three_node_cluster_two_subnets.png\" alt=\"three node cluster two subnets\" class=\"wp-image-36402\" width=\"285\" height=\"278\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/three_node_cluster_three_subnets.png\" alt=\"three node cluster three subnets\" class=\"wp-image-36401\" width=\"284\" height=\"280\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Remove the Node from the AG then the Cluster<\/h2>\n\n\n\n<p>1. Log into SSMS, connect to the Primary. <br>2. Set the DR server as synchronize if it is not already. We want the transactions to be in sync to the DR server before we remove it from the AG.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expand <strong>AlwayOn High Availability<\/strong>, <strong>Availability Groups<\/strong>, <strong>your AG<\/strong>,<strong> Availability Replicas<\/strong>. Right click on it and choose <strong>Properties<\/strong>. Verify or change the Availability Mode to Synchronous commit.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"310\" height=\"367\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/alwayon_high_availability_replicas_properties_1.png\" alt=\"alwayon high availability replicas properties\" class=\"wp-image-36412\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"724\" height=\"581\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/availabilty_group_properties_2.png\" alt=\"availabilty group properties\" class=\"wp-image-36414\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right click AlwaysOn High Availability and click the Show Dashboard and verify all databases on all nodes are showing Failover Readiness is set to No Data Loss. You may need to refresh often to show the new status.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"776\" height=\"406\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/show_dashboard_all_failover_readiness_no_data_loss_3.png\" alt=\"show dashboard all failover readiness no data loss\" class=\"wp-image-36429\"\/><\/figure>\n\n\n\n<p>3. Disable Transaction log backup on <strong>ALL<\/strong> nodes.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expand <strong>SQL Server Agent<\/strong>,<strong> Jobs<\/strong><\/li>\n\n\n\n<li>Right click on your Transaction job and choose <strong>Disable<\/strong>. This needs to be done on <strong>ALL <\/strong>nodes that are part of the AG.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"149\" height=\"224\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/disable_transaction_log_backup_4.png\" alt=\"disable transaction log backup\" class=\"wp-image-36418\"\/><\/figure>\n\n\n\n<p>4. Remove the Node (DR node) from the AG.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expand <strong>AlwayOn High Availability<\/strong>, <strong>Availability Groups<\/strong>, <strong>your AG<\/strong>,<strong> Availability Replicas<\/strong>. Right click on it and choose <strong>Remove from Availability Group&#8230; <\/strong>Follow the prompts to remove it out.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"438\" height=\"156\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/remove_node_from_AG_5.png\" alt=\"remove node from AG\" class=\"wp-image-36425\"\/><\/figure>\n\n\n\n<p>5. Remove the no longer used DR listener IP from the AG<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Open <strong>Failover Cluster Manager<\/strong>.<\/li>\n\n\n\n<li>Remove the listener IP from the AG.\n<ul class=\"wp-block-list\">\n<li>Click <strong>Roles<\/strong>, then highlight the name of your AG.<\/li>\n\n\n\n<li>Click on the <strong>Resources<\/strong> tab.<\/li>\n\n\n\n<li>Highlight the IP you want to remove (it should be offline <img decoding=\"async\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/2959940b31edeec2b83ce80b89c40137-10.png\" alt=\"\"> ), right click on it and choose <strong>Remove<\/strong>. <\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"988\" height=\"793\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/remove_DR_listener_IP_from_AG_6.png\" alt=\"remove DR listener IP from AG\" class=\"wp-image-36424\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Evict the node from the cluster.\n<ul class=\"wp-block-list\">\n<li>Click on <strong>Nodes<\/strong>.<\/li>\n\n\n\n<li>Right click on the Node you want to evict and choose <strong>More Actions<\/strong>, <strong>Evict<\/strong>. Click <strong>Yes<\/strong> to evict the node out of the cluster.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"780\" height=\"357\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/evict_node_from_cluster_7.png\" alt=\"evict node from cluster\" class=\"wp-image-36420\"\/><\/figure>\n\n\n\n<p>6. Verify the preferred owners are set to the remaining nodes.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Click <strong>Roles<\/strong>, then highlight the name of your AG.<\/li>\n\n\n\n<li>Right click on the AG and click<strong> Properties<\/strong>. Verify both primary and secondary <\/li>\n\n\n\n<li>Verify both primary and secondary have a check mark next to preferred owners.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"642\" height=\"445\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/verify_preferred_owners_set_to_remaining_nodes_8.png\" alt=\"verify preferred owners set to remaining nodes\" class=\"wp-image-36433\"\/><\/figure>\n\n\n\n<p>7. Remove the old cluster IP and add the new one.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>In <strong>Failover Cluster Manager<\/strong>, click on cluster name, go to <strong>Cluster Core<\/strong><strong>Resources <\/strong>(at the bottom of the screen).\n<ul class=\"wp-block-list\">\n<li>Right click on Server Name AG name go to <strong>Properties<\/strong>. Highlight the old cluster IP and click <strong>Remove<\/strong>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"899\" height=\"655\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_new_cluster_IP_12.png\" alt=\"remove old cluster IP add new one\" class=\"wp-image-36409\"\/><\/figure>\n\n\n\n<p>8. Validate the cluster. Make sure there are no errors within the report. Look at what the warnings say. Fix if need be.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"451\" height=\"469\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/validate_cluster_10.png\" alt=\"validate cluster\" class=\"wp-image-36432\"\/><\/figure>\n\n\n\n<p>9. You are now ready to VMotion, change IP, etc. the DR server.<\/p>\n\n\n\n<p>10. Once you are done, update DNS with the new IP address for the node and cluster for that subnet. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Add the Node back into the Cluster then AG<\/h2>\n\n\n\n<p>1.Add the node back into the cluster. Re-Validate the cluster. Make sure there are no errors.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add the Node back to the cluster.\n<ul class=\"wp-block-list\">\n<li>In <strong>Failover Cluster Manager<\/strong>, click on cluster name, right click on <strong>Nodes<\/strong> and choose <strong>Add Node&#8230;<\/strong><\/li>\n\n\n\n<li>Follow the steps to add the node back into the Cluster. <\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"274\" height=\"159\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_node_back_11.png\" alt=\"add node back\" class=\"wp-image-36410\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add the new cluster IP.\n<ul class=\"wp-block-list\">\n<li>You will need a new IP address for the cluster (this is NOT the server IP address it is a separate IP address for the cluster for that subnet). You may or may not be asked to run a validate cluster test. If you do, please proceed. If not, run it after adding the node into the cluster.<\/li>\n\n\n\n<li>In <strong>Failover Cluster Manager<\/strong>, click on cluster name, go to <strong>Cluster Core Resources <\/strong>(at the bottom of the screen).\n<ul class=\"wp-block-list\">\n<li>Right click on Server Name AG name go to <strong>Properties<\/strong>. Highlight the old cluster IP and click <strong>Add<\/strong> to add new cluster IP in the new subnet.<\/li>\n\n\n\n<li>It will show the new cluster IP as offline and it should since only one Cluster IP can be active at a time.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"899\" height=\"655\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_new_cluster_IP_12.png\" alt=\"remove old cluster IP add new one\" class=\"wp-image-36409\"\/><\/figure>\n\n\n\n<p>2. Change the Node to be a non-voting node.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>0 means the node has no vote. 1 means the node has a vote. Changing cluster settings for votes.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"839\" height=\"123\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/change_node_to_nonvoting_13.png\" alt=\"change node to nonvoting\" class=\"wp-image-36417\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Changing cluster settings for votes.\n<ul class=\"wp-block-list\">\n<li>Microsoft likes odd number of votes for clusters (the number of nodes plus if you have quorum i.e. cloud witness, file share, etc. We have three nodes and a file share as quorum witness that is why we are setting the DR server to NOT be a voting server. If this server location is far from the primary and secondary servers, we do not want its vote to affect the cluster due to network latency, hiccups, etc.<\/li>\n\n\n\n<li>Right click the cluster name, <strong>More Actions<\/strong>, <strong>Configure Cluster Quorum Settings<\/strong>, <strong>Advanced quorum configuration<\/strong>, select the node you do not want to have a vote, then keep going until you finish the configuration. This change is dynamic.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"625\" height=\"247\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/change_cluster_settings_for_votes_14.png\" alt=\"change cluster settings for votes\" class=\"wp-image-36416\"\/><\/figure>\n\n\n\n<p>3. Fix the listener to use the new IP address. <strong>(Pick one option)<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>This is faster<\/strong>. In <strong>Failover Cluster Manager<\/strong>, choose <strong>Roles<\/strong>, click on your AG. Click on the <strong>Resources<\/strong> Tab. Expand <strong>Server Name<\/strong>. Right click on the listener name go to <strong>Properties<\/strong>. <strong>Remove <\/strong>the IP of the old listener if you did not already remove it. <strong>Add <\/strong>the new listener for the new subnet. Click <strong>OK<\/strong>. Refresh.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"843\" height=\"791\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/remove_old_cluster_IP_add_new_one_9.png\" alt=\"add_new_cluster_IP\" class=\"wp-image-36426\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You may have to restart the AG within <strong>Failover Cluster Manager<\/strong> if it shows the AG as offline. If so, right click on the AG under <strong>Other Resources<\/strong> and click <strong>Bring Online<\/strong>. This will start the listener as well.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"460\" height=\"92\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/other_resources_bring_online_18.png\" alt=\"other resources bring online\" class=\"wp-image-36423\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OR<\/strong><\/li>\n\n\n\n<li>Add the listener in when you add the Node back into the AG.<\/li>\n<\/ul>\n\n\n\n<p>4. Using SSMS, add the node to the AG.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Expand <strong>AlwaysOn High Availability<\/strong> and your AG.<\/li>\n\n\n\n<li>Right click on <strong>Availability Replicas<\/strong> and click on <strong>Add Replica\u2026<\/strong><\/li>\n\n\n\n<li>Go through the wizard to add your replica back into the AG. Set the Node to be synchronized temporarily. You want to use a JOIN ONLY to add the databases into the AG since we do not have to delete the databases in the node you are adding back into the AG. Since we turned off the transaction log backups, we should be fine with the AGs going online once you join the servers. If you did not add the new Listener IP address in Step #4 above then you need to make sure and add the listener IP for the new subnet in this step. If you don&#8217;t, the node will fail to join the AG and you will have to add the listener in using the Failover Cluster Manager, then join that node to the AG.\n<ul class=\"wp-block-list\">\n<li>This step may take some time to add the Node and databases back into the AG especially if there is a big difference in location and a large amount of databases. Be patient it will finish.<\/li>\n\n\n\n<li>If some of your databases do not join into the AG, go to the <strong>Troubleshooting Steps<\/strong> section of this blog.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"295\" height=\"115\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_replica_19.png\" alt=\"add replica\" class=\"wp-image-36411\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Open the Dashboard and verify all databases on all nodes are showing Failover Readiness is set to No Data Loss. You may need to refresh often to show the new status.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"776\" height=\"406\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/show_dashboard_all_failover_readiness_no_data_loss_3.png\" alt=\"show dashboard all failover readiness no data loss\" class=\"wp-image-36429\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Change the Availability Mode for this DR server back to Asynchronous commit. IF that is what you want this server to be set to. If the server&#8217;s location is far from the primary and secondary and the network bandwidth is slow or prone to hiccups it is recommended to set the DR server to Asynchronous commit.\n<ul class=\"wp-block-list\">\n<li>Expand <strong>AlwayOn High Availability<\/strong>, <strong>Availability Groups<\/strong>, your AG,<strong> Availability Replicas<\/strong>. Right click on it and choose <strong>Properties<\/strong>. Verify or change the Availability Mode is set to Asynchronous commit.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"729\" height=\"584\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/availability_properties_19.png\" alt=\"availability properties\" class=\"wp-image-36413\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Open the Dashboard and the Failover Readiness for the databases on the DR server will show as Data Loss due to changing the Availability Mode. If they still show as No Data Loss, you can refresh until that changes.<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"780\" height=\"405\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/show_dashboard_all_failover_readiness_data_loss_20.png\" alt=\"show dashboard all failover readiness data loss\" class=\"wp-image-36428\"\/><\/figure>\n\n\n\n<p>5. Re-enable the transaction log backup jobs on all nodes.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable Transaction log backup on <strong>ALL<\/strong> nodes.\n<ul class=\"wp-block-list\">\n<li>Expand <strong>SQL Server Agent<\/strong>,<strong> Jobs<\/strong><\/li>\n\n\n\n<li>Right click on your Transaction job and choose <strong>Enable<\/strong>. This needs to be done on <strong>ALL <\/strong>nodes that are part of the AG.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"218\" height=\"231\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/enable_transaction_job_21.png\" alt=\"enable transaction job\" class=\"wp-image-36419\"\/><\/figure>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>***NOTE:<\/strong> Kick off the transaction log backups on all nodes unless you know which server those backups should run from.<\/li>\n<\/ul>\n\n\n\n<p>The thought of moving a server and changing the IP address of that server from one data center to another may seem daunting but it can be done successfully. Hopefully you can test this out in a development environment but that is not always available. So, it is imperative that you understand the steps involved and are as prepared as possible.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Troubleshooting steps<\/h2>\n\n\n\n<p>While the DR server and databases are being added back into the AG, you may see some databases error out during the join process. The DR server will join fine (if you add the new listener in using the Failover Cluster Manager or when you add the node to the AG) but you may see that some, if not all, of the databases did not join to the AG. This could happen if you forgot to turn off the transaction log backups or some other process made a transaction log backup during this transition period.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Adding transaction log backups to a database in Restoring State<\/h2>\n\n\n\n<p>1.Using SSMS, connect to the DR server. Expand <strong>Availability Groups<\/strong>, your AG, <strong>Availability Databases<\/strong>. You will see your database and it will have a Yellow <strong>(!)<\/strong> exclamation mark.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"257\" height=\"135\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/availbility_databases_22.png\" alt=\"availability databases\" class=\"wp-image-36415\"\/><\/figure>\n\n\n\n<p>2. Look at your backup chain, find your transaction log backups and load them. You can script out the restore or use the GUI to load the transaction logs. Via the GUI, on the secondary, right click on the DB that shows <strong>Restoring<\/strong>, click <strong>Tasks<\/strong>, <strong>Restore<\/strong>, <strong>Transaction Log\u2026 <\/strong>Once you restored all of the transaction logs, keep the database in <strong>RESTORE IN NORECOVERY<\/strong>. The database has to be in Restoring status in order to join it.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"832\" height=\"305\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/transaction_log_23.png\" alt=\"transaction log\" class=\"wp-image-36430\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"497\" height=\"67\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/leave_database_non-operational_24.png\" alt=\"leave database non-operational\" class=\"wp-image-36421\"\/><\/figure>\n\n\n\n<p>3. To add the database to the AG, right click on the database that has an exclamation<strong> (!)<\/strong> mark in front of it and click &#8220;<strong>Join to Availability Group\u2026<\/strong>&#8220;.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"376\" height=\"248\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_database_to_AG_join_to_availability_group_25.png\" alt=\"add database to AG join to availability group\" class=\"wp-image-36408\"\/><\/figure>\n\n\n\n<p>4. If you loaded all of the transaction logs, the database will join the AG successfully.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"271\" height=\"222\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/transaction_logs_loaded_database_joins_AG_successfully_26.png\" alt=\"transaction logs loaded database joins AG successfully\" class=\"wp-image-36431\"\/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Restore FULL backup<\/h2>\n\n\n\n<p>If you can&#8217;t find the transaction logs or you do not want to go through that process of loading them, you can make a FULL backup as COPY ONLY and restore it.<br>1. Make a FULL backup with copy only, copy the file to the DR server and restore it, just make sure and set the Recovery state as <strong>RESTORE IN NORECOVERY<\/strong>. The database has to be in Restoring status in order to join it to the Availability Group.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"480\" height=\"59\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/restore_full_backup_24.png\" alt=\"restore full backup\" class=\"wp-image-36427\"\/><\/figure>\n\n\n\n<p>2. To add the database to the AG, right click on the database that has an exclamation<strong> (!)<\/strong> mark in front of it and click &#8220;<strong>Join to Availability Group\u2026<\/strong>&#8220;.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"376\" height=\"248\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/add_database_to_AG_join_to_availability_group_25.png\" alt=\"add database to AG join to availability group\" class=\"wp-image-36408\"\/><\/figure>\n\n\n\n<p>3. If you loaded all of the transaction logs, the database will join the AG successfully.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img loading=\"lazy\" decoding=\"async\" width=\"271\" height=\"222\" src=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/transaction_logs_loaded_database_joins_AG_successfully_26.png\" alt=\"transaction logs loaded database joins AG successfully\" class=\"wp-image-36431\"\/><\/figure>\n","protected":false},"excerpt":{"rendered":"<p>There may be a situation when you need to move one of your servers that is part of an Availability Group to a different data center and the IP address for that server will change. In this example, we will be moving a DR node from one data center to another and change the IP [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":36477,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":"","_et_gb_content_width":"","content-type":"","footnotes":""},"categories":[4166,55],"tags":[1957,3989,60],"class_list":["post-36399","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-sql-server","tag-always-on","tag-cluster","tag-sql-server"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.1 (Yoast SEO v27.1.1) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>Migrating Your AlwaysOn DR Node to a Different Location - Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts<\/title>\n<meta name=\"description\" content=\"&quot;Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.&quot;\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Migrating Your AlwaysOn DR Node to a Different Location\" \/>\n<meta property=\"og:description\" content=\"&quot;Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.&quot;\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts\" \/>\n<meta property=\"article:published_time\" content=\"2019-08-22T12:08:17+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-08-11T14:51:13+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"557\" \/>\n\t<meta property=\"og:image:height\" content=\"291\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"XTIVIA\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@virtual_dba\" \/>\n<meta name=\"twitter:site\" content=\"@virtual_dba\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"XTIVIA\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"16 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\"},\"author\":{\"name\":\"XTIVIA\",\"@id\":\"https:\/\/virtual-dba.com\/#\/schema\/person\/2d86f74bed0c3f1b49100f7fdf7d78d1\"},\"headline\":\"Migrating Your AlwaysOn DR Node to a Different Location\",\"datePublished\":\"2019-08-22T12:08:17+00:00\",\"dateModified\":\"2023-08-11T14:51:13+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\"},\"wordCount\":1988,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/virtual-dba.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg\",\"keywords\":[\"always on\",\"Cluster\",\"sql server\"],\"articleSection\":[\"Blog\",\"SQL Server\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\",\"url\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\",\"name\":\"Migrating Your AlwaysOn DR Node to a Different Location - Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts\",\"isPartOf\":{\"@id\":\"https:\/\/virtual-dba.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg\",\"datePublished\":\"2019-08-22T12:08:17+00:00\",\"dateModified\":\"2023-08-11T14:51:13+00:00\",\"description\":\"\\\"Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.\\\"\",\"breadcrumb\":{\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage\",\"url\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg\",\"contentUrl\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg\",\"width\":557,\"height\":291},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtual-dba.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Migrating Your AlwaysOn DR Node to a Different Location\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtual-dba.com\/#website\",\"url\":\"https:\/\/virtual-dba.com\/\",\"name\":\"Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts\",\"description\":\"Remote Database Administration\",\"publisher\":{\"@id\":\"https:\/\/virtual-dba.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtual-dba.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/virtual-dba.com\/#organization\",\"name\":\"Virtual-DBA: Remote DBA | Remote Database Administration\",\"alternateName\":\"Virtual-DBA powered by XTIVIA\",\"url\":\"https:\/\/virtual-dba.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtual-dba.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/V-DBA-Database-Services-and-Support-Featured-Logo.jpg\",\"contentUrl\":\"https:\/\/virtual-dba.com\/wp-content\/uploads\/V-DBA-Database-Services-and-Support-Featured-Logo.jpg\",\"width\":557,\"height\":291,\"caption\":\"Virtual-DBA: Remote DBA | Remote Database Administration\"},\"image\":{\"@id\":\"https:\/\/virtual-dba.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/x.com\/virtual_dba\",\"https:\/\/www.linkedin.com\/showcase\/36220649\/\",\"https:\/\/www.youtube.com\/channel\/UCx3AIeUQ2ziTLKZSJDZ-SEg\"],\"description\":\"Eliminate database downtime and spiraling costs with XTIVIA\u2019s Virtual-DBA. In today\u2019s always-on business world, gaps in 24x7 on-call DBA support, neglected maintenance and security, or a stretched team struggling with overwhelming workloads can lead to costly disruptions and threaten business continuity. XTIVIA\u2019s Virtual-DBA provides the immediate, expert database administration you need, exactly when you need it, ensuring optimal performance, ironclad security, and significant cost savings without the burden of expanding your in-house team. The goal of Virtual-DBA is to provide a cost-effective solution for organizations seeking to optimize the security, management, maintenance, availability, and performance of their critical business systems, whether self-managed or cloud-managed (e.g., AWS RDS, Azure SQL Database). We accomplish this through a comprehensive remote DBA service offering designed specifically to meet the Oracle\u00ae, DB2\u00ae, Informix\u00ae, MySQL\u2122, PostgreSQL\u00ae, MongoDB\u00ae, MariaDB, and Microsoft SQL Server\u00ae, CockroachDB, Databricks, AWS, and Azure needs of our clients.\",\"email\":\"info@xtivia.com\",\"telephone\":\"8886853101\",\"legalName\":\"XTIVIA, Inc\",\"foundingDate\":\"1992-05-01\",\"numberOfEmployees\":{\"@type\":\"QuantitativeValue\",\"minValue\":\"201\",\"maxValue\":\"500\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtual-dba.com\/#\/schema\/person\/2d86f74bed0c3f1b49100f7fdf7d78d1\",\"name\":\"XTIVIA\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtual-dba.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0d3648a00e319a37cf8d6d19f762acfbbb4fd0320fd8a6d6b1e64f44a2a6f259?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/0d3648a00e319a37cf8d6d19f762acfbbb4fd0320fd8a6d6b1e64f44a2a6f259?s=96&d=mm&r=g\",\"caption\":\"XTIVIA\"},\"url\":\"https:\/\/virtual-dba.com\/author\/xtivia\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Migrating Your AlwaysOn DR Node to a Different Location - Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts","description":"\"Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.\"","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/","og_locale":"en_US","og_type":"article","og_title":"Migrating Your AlwaysOn DR Node to a Different Location","og_description":"\"Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.\"","og_url":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/","og_site_name":"Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts","article_published_time":"2019-08-22T12:08:17+00:00","article_modified_time":"2023-08-11T14:51:13+00:00","og_image":[{"width":557,"height":291,"url":"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg","type":"image\/jpeg"}],"author":"XTIVIA","twitter_card":"summary_large_image","twitter_creator":"@virtual_dba","twitter_site":"@virtual_dba","twitter_misc":{"Written by":"XTIVIA","Est. reading time":"16 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#article","isPartOf":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/"},"author":{"name":"XTIVIA","@id":"https:\/\/virtual-dba.com\/#\/schema\/person\/2d86f74bed0c3f1b49100f7fdf7d78d1"},"headline":"Migrating Your AlwaysOn DR Node to a Different Location","datePublished":"2019-08-22T12:08:17+00:00","dateModified":"2023-08-11T14:51:13+00:00","mainEntityOfPage":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/"},"wordCount":1988,"commentCount":0,"publisher":{"@id":"https:\/\/virtual-dba.com\/#organization"},"image":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage"},"thumbnailUrl":"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg","keywords":["always on","Cluster","sql server"],"articleSection":["Blog","SQL Server"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/","url":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/","name":"Migrating Your AlwaysOn DR Node to a Different Location - Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts","isPartOf":{"@id":"https:\/\/virtual-dba.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage"},"image":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage"},"thumbnailUrl":"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg","datePublished":"2019-08-22T12:08:17+00:00","dateModified":"2023-08-11T14:51:13+00:00","description":"\"Migrating SQL Server AlwaysOn DR Node to a Different Location: Step-by-Step Guide by XTIVIA.\"","breadcrumb":{"@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#primaryimage","url":"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg","contentUrl":"https:\/\/virtual-dba.com\/wp-content\/uploads\/Migrating-Your-AlwaysOn-DR-Node-to-a-Different-Location.jpg","width":557,"height":291},{"@type":"BreadcrumbList","@id":"https:\/\/virtual-dba.com\/blog\/migrating-your-alwayson-dr-node-to-a-different-location\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtual-dba.com\/"},{"@type":"ListItem","position":2,"name":"Migrating Your AlwaysOn DR Node to a Different Location"}]},{"@type":"WebSite","@id":"https:\/\/virtual-dba.com\/#website","url":"https:\/\/virtual-dba.com\/","name":"Virtual-DBA Remote DBA Services &amp; Support - Certified Database Experts","description":"Remote Database Administration","publisher":{"@id":"https:\/\/virtual-dba.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtual-dba.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/virtual-dba.com\/#organization","name":"Virtual-DBA: Remote DBA | Remote Database Administration","alternateName":"Virtual-DBA powered by XTIVIA","url":"https:\/\/virtual-dba.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtual-dba.com\/#\/schema\/logo\/image\/","url":"https:\/\/virtual-dba.com\/wp-content\/uploads\/V-DBA-Database-Services-and-Support-Featured-Logo.jpg","contentUrl":"https:\/\/virtual-dba.com\/wp-content\/uploads\/V-DBA-Database-Services-and-Support-Featured-Logo.jpg","width":557,"height":291,"caption":"Virtual-DBA: Remote DBA | Remote Database Administration"},"image":{"@id":"https:\/\/virtual-dba.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/virtual_dba","https:\/\/www.linkedin.com\/showcase\/36220649\/","https:\/\/www.youtube.com\/channel\/UCx3AIeUQ2ziTLKZSJDZ-SEg"],"description":"Eliminate database downtime and spiraling costs with XTIVIA\u2019s Virtual-DBA. In today\u2019s always-on business world, gaps in 24x7 on-call DBA support, neglected maintenance and security, or a stretched team struggling with overwhelming workloads can lead to costly disruptions and threaten business continuity. XTIVIA\u2019s Virtual-DBA provides the immediate, expert database administration you need, exactly when you need it, ensuring optimal performance, ironclad security, and significant cost savings without the burden of expanding your in-house team. The goal of Virtual-DBA is to provide a cost-effective solution for organizations seeking to optimize the security, management, maintenance, availability, and performance of their critical business systems, whether self-managed or cloud-managed (e.g., AWS RDS, Azure SQL Database). We accomplish this through a comprehensive remote DBA service offering designed specifically to meet the Oracle\u00ae, DB2\u00ae, Informix\u00ae, MySQL\u2122, PostgreSQL\u00ae, MongoDB\u00ae, MariaDB, and Microsoft SQL Server\u00ae, CockroachDB, Databricks, AWS, and Azure needs of our clients.","email":"info@xtivia.com","telephone":"8886853101","legalName":"XTIVIA, Inc","foundingDate":"1992-05-01","numberOfEmployees":{"@type":"QuantitativeValue","minValue":"201","maxValue":"500"}},{"@type":"Person","@id":"https:\/\/virtual-dba.com\/#\/schema\/person\/2d86f74bed0c3f1b49100f7fdf7d78d1","name":"XTIVIA","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtual-dba.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/0d3648a00e319a37cf8d6d19f762acfbbb4fd0320fd8a6d6b1e64f44a2a6f259?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/0d3648a00e319a37cf8d6d19f762acfbbb4fd0320fd8a6d6b1e64f44a2a6f259?s=96&d=mm&r=g","caption":"XTIVIA"},"url":"https:\/\/virtual-dba.com\/author\/xtivia\/"}]}},"_links":{"self":[{"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/posts\/36399","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/comments?post=36399"}],"version-history":[{"count":0,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/posts\/36399\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/media\/36477"}],"wp:attachment":[{"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/media?parent=36399"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/categories?post=36399"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtual-dba.com\/wp-json\/wp\/v2\/tags?post=36399"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}