Dbvisit Standby SQL is a software product designed to provide fast & reliable Disaster Recovery (DR) setup for Microsoft SQL Server. In addition to being feature-rich, Standby SQL is first and foremost intended to be extremely simple to both configure and use, even for non-expert users and “accidental DBAs”.

The Standby SQL software is composed of two components: Standby SQL Agent and Standby SQL Control Center.

The Standby SQL Agent is an application that must be deployed on the database host, i.e. the location of the SQL Server Instance. This Agent is what connects to your Instance & Databases and liaises with the Control Center (more on this below) to perform all the actions that Standby SQL provides. You will therefore need to install the Standby SQL Agent at least twice - once on each of the SQL Server Instance locations that you are planning to use. If both of the Instances you intend to use are on the same host/location, a single Agent installation is sufficient, however such an arrangement would not allow for true DR, as the single host represents a single point of failure for both of your Instances.

The Standby SQL Control Center is the brains of the operation, the central command & communications hub that works with and directs/coordinates any number of Standby SQL Agents. It also includes a webserver and the browser-based GUI used to setup/control the product. It is therefore recommended that this be installed on an independent, third location, separate from any of the SQL Server Instance hosts you intend to use. If you must install the Control Center on the same location as one of the Instances, you should use the location for the Standby Instance.

Basic Concepts

Dbvisit Standby SQL works on the basis of a Disaster Recovery Configuration (DRC), which is a defined relationship between a set of Databases within two SQL Server Instances. This “Database Set” can then be assigned either a Primary or Standby role.

A Primary Database is one which is active (i.e. online) and in-use. Almost always, this will be your intended source of information, e.g. a production database. This is the Database you are interested in protecting via a DR configuration.

A Standby Database is one which is not active (i.e. in a recovering state), and is intended to be the target for the Primary Database to replicate to, e.g. your “backup” database. This is the Database that should be kept in-sync with the Primary, and the one which you expect to be able to switch to in case of an emergency.

Installation

Both of the Windows & Linux installers ask for the same basic user input, and install the same basic components. The only exceptions to this will be discussed briefly below.

You may select to install either the Standby SQL Agent or the Standby SQL Control Center, or both. For your SQL Server Instance locations, you need only install the Agent. As mentioned above, it is recommended you install the Control Center separately on a third location, otherwise you may install it on your Standby location at the same time as the Agent.

Brief additional descriptions for some of the installer input fields:

• Control Center Web Server Port: this is the port that the browser-based GUI will become available on after installation. For example, if you are accessing the GUI locally (i.e. from the same host where the Control Center is installed), you would access it by going to https://localhost:[THISPORT].

• Agent Communications Port: this port is used by both the Standby SQL Agents & Control Center for communication between each other. Ensure this port is open, and is set the same installation-wide.

• Linux-specific: If you answer No to the “do you want to automatically set up services?” question, the setup script will present you with a list of the required “actions to complete installation” once it is finished. Please run the commands displayed to start the required services. You can refer to the full Linux installation guide here: https://dbvisit.atlassian.net/wiki/spaces/DRI/pages/2048851973/Linux+Installation.

• Windows-specific: User Domain/User/Password - the user specified here needs to have access rights to the SQL Server Instance if you want to use Windows Authorization later on to connect to the Instance. Otherwise, you can ignore these and manually connect to the Instance later using SQL Server Mixed-Mode Authentication.

Linux Installation

This section will provide you with a quick overview of installing Dbvisit Standby for SQL on a Linux based system

• Create UNIX users user which the Dbvisit Standby SQL services you will run, e.g.

  No Format
  # useradd --system dbvisit

  
  

• Create base software folder where the Dbvisit Standby for SQL will be installed into, example /usr/dbvisit

  No Format
  # mkdir /usr/dbvisit # chown -R dbvisit:dbvisit /usr/dbvisit

  
  

• Download the software to your system

  Example below the installation file is places in the temporary "install_files" folder under the user home directory

  No Format
  ~/install_files/linux-v0.8.5DEV-4-gac1bcc3.tar.gz

  
  

• Extract the files into a temporary location, e.g.

  No Format
  cd ~/install_files/ tar xzf linux-v0.8.5DEV-4-gac1bcc3.tar.gz

  
  

• Run the setup program as the user that will run the Dbvisit Standby for SQL software.

  No Format

  dbvisit@dbv1:~/install_files $ ls linux-v0.8.5DEV-4-gac1bcc3.tar.gz dbvisit@dbv1:~/install_files $ tar xzf linux-v0.8.5DEV-4-gac1bcc3.tar.gz dbvisit@dbv1:~/install_files $ ls linux-v0.8.5DEV-4-gac1bcc3.tar.gz setup-standby-v0.8.5DEV-4-gac1bcc3 dbvisit@dbv1:~/install_files $ ./setup-standby-v0.8.5DEV-4-gac1bcc3 +---------------------------------------------------------------------------------------------------+ | ____ __ _ _ __ _____ __ ____ _____ ____ __ | | / __ \/ /_ _ __(_)____(_) /_ / ___// /_____ _____ ____/ / /_ __ __ / ___// __ \ / / | | / / / / __ \ | / / / ___/ / __/ \__ \/ __/ __ `/ __ \/ __ / __ \/ / / / \__ \/ / / / / / | | / /_/ / /_/ / |/ / (__ ) / /_ ___/ / /_/ /_/ / / / / /_/ / /_/ / /_/ / ___/ / /_/ / / /___ | | /_____/_.___/|___/_/____/_/\__/ /____/\__/\__,_/_/ /_/\__,_/_.___/\__, / /____/\___\_\/_____/ | | /____/ Copyright @2020 | +---------------------------------------------------------------------------------------------------+ Welcome to Dbvisit Standby SQL setup version v0.8.5DEV-4-gac1bcc3. ? Which directory should the software be installed into? /usr/dbvisit ? Which components do you wish to use on this host? Control Center, Agent - - - You are now configuring the Dbvisit Standby SQL Control Center - - - The Control Center will listen on the following discovered addresses: - 127.0.0.1 - 172.17.0.2 ? Control Center Web Server Port: 12345 ? Agent Communications Port: 4222 - - - Dbvisit Standby SQL Control Center configuration finished - - - - - - You are now configuring the Dbvisit Standby SQL Agent - - - ? Default location for SQL Server backup files /usr/dbvisit/standby/backup ? Resolvable Host Name: dbv1 ? Control Center Address: 127.0.0.1 ? Agent Communications Port: 4222 - - - Dbvisit Standby SQL Agent configuration finished - - - - - - Ready to perform installation - - - ? Do you wish to proceed with the setup using the supplied configuration options? Proceed with setup - - - Performing installation - - - Copying software files to '/usr/dbvisit/standby'... Writing Control Center configuration file '/usr/dbvisit/standby/conf/standbycontrol.ini'... Writing Agent configuration file '/usr/dbvisit/standby/conf/standbyagent.ini'... - - - Installation successful! - - - To enable the installed Dbvisit Standby SQL components to run as system services, you will need to execute some commands as the "root" user in order to complete the setup. To install the system service(s), you can run, substituting the name of the user to run as if it is different from the current user: sudo /usr/dbvisit/standby/bin/standbycontrol service install --user oracle sudo /usr/dbvisit/standby/bin/standbyagent service install --user oracle To start the system service(s), you can run: sudo /usr/dbvisit/standby/bin/standbycontrol service start sudo /usr/dbvisit/standby/bin/standbyagent service start

  
  

Services

Assuming you choose to allow the setup program to manage OS services, and that you’re using a Linux distribution that uses systemd for OS services, you can use systemctl to control the service(s).

To check whether the Agent service is running: 

sudo systemctl status standbyagent.service

Example, to check where the Control Center service is running: 

sudo systemctl status standbycontrol.service

Log files

Once the service has started, there should be a log file and some repository files present in the DBVISIT_BASE/standby/log folder

Upgrade

1. Uninstall (we don’t currently support upgrading repositories so they must be removed when upgrading)

2. Remove the files extracted from the installation package

   NOTE - you choose the location of these files when you extract them - there is no default

   No Format
   rm -r Dbvisit/

   
   

3. Run the setup program again

Uninstall

There is no automated uninstall procedure currently.

1. Stop services

   No Format
   sudo /usr/dbvisit/standby/bin/standbyagent service stop sudo /usr/dbvisit/standby/bin/standbycontrol service stop

   
   

2. Uninstall services

   No Format
   sudo /usr/dbvisit/standby/bin/standbyagent service uninstall sudo /usr/dbvisit/standby/bin/standbycontrol service uninstall

   
   

3. Remove logs and repositories

   NOTE - if you changed the default path during installation, you will have to make sure you use that when you run the command below

   No Format
   sudo rm -rf /usr/dbvisit/standby

   
   

Windows Installation

This section will provide you with a quick overview of installing Dbvisit Standby for SQL on a Windows-based system. The windows installation is similar to Dbvisit standby installation and it is easy and straightforward.

Step 1

Double click the Standby.msi [ 1 ] file which will lead to the setup wizard and click Next [ 2 ]

Step 2

Accept the license agreement and move to the next step

Step 3

This will prompt you by default to install both Dbvisit Standby SQL Control Center [ 1 ] and the Dbvisit Standby SQL Agent [ 2 ]. The location is by default C:\Program Files\Dbvisit\standby [ 3 ]. You can browse to a different location and point the installation to a different drive/folder.

Step 4

The Control Center or the GUI component will listen to the discovered addresses [ 1 ]. The control center webserver port is by default 12345 [ 2 ] and the Agent communication port is 4222 [ 3 ]

Step 5

This is a very important part of the installation. 

1. The resolvable Host Name is automatically populated 
2. The Control Center Address will be based on the server in which the web interface is installed. In the below case the Control center is installed in the same host.
3. Username and Password credentials for the host in which the standby component is installed.

Step 6

If the credentials and details are provided correctly in step 5 the installation should proceed without issues and the services would also be started 

Step 7

When installing components in the primary server, you don't have to install the SQL Control Center. You just have to install the Dbvisit Standby SQL Agent.

Configuration

Once everything is installed, you can begin configuring the product for your needs by accessing the browser-based GUI, available at the Control Center’s installation address + the Web Server port you specified during installation (as mentioned above). For example: https://localhost:12345.

For now, you can login using any username and the password “password” - user management is coming soon.

Dbvisit Standby SQL has no command line client - the browser GUI is the only way to use & configure the product. This GUI is always available as long as the Control Center process is running.

Registering Hosts & Instances

Begin by registering a Host and any Instances on it - the GUI will prompt you to do so.

A Host is a location with a Standby SQL Agent installed and running - this should have been done during installation above. Any available Host will auto-announce: this means it will automatically show up in the Discovered Hosts panel. If your desired Host is not shown here, this means something went wrong during installation - the most common reason is specifying the wrong Agent Communications port, or not having this port correctly open/routed through your network.

Step1

The below Figure will show the discovered hosts in the the central console.

Step2

You will have to register the discovered host, when you click on Register Host you will see the below options

1. This is the communication port between your Primary and Standby host.
2. The default location where all your full backups(taken during the CSD) and the transaction log backups will be present. This location must be changed to a different location where there is enough space for backups to be present.
3. 4. This depends on the authentication type of your SQL server instance and also depends on which you want to use to register the host with Dbvisit central console.

Step3

I have chosen the Windows Authentication and you get the below results

1. The SQL Server instance name.
2. Confirm if the test connection was successful and the Dbvisit components are able to connect to the SQL server instance.
3. Available user databases.
4. Click Confirm&Register host to register it to the central console.

Step4

Both the primary and standby host has been registered with the central console. We recommend using the same authentication type to register both primary and standby hosts.

You will need to register at least 2 Hosts to proceed 

Creating Disaster Recovery Configurations (DRCs)

Once you have 2 Hosts registered, you can create your first DRC.Database Configurations

A DRC defines a set of Databases on the Primary Instance, and controls the existence/synchronization of these same databases on the Standby Instance.

Brief additional descriptions for some of the DRC Creation input fields:

• DRC Name: can be whatever you want

• Licence Key: you must have a valid licence to use the Standby SQL MVP. A licence should be provided to you by Dbvisit. Each DRC must have its own, unique licence.

• Databases: select all databases that you want to be a part of this DRC. Using this DRC, you will be able to run any Database Action on any Database within it either individually or affecting all Databases at the same time. However, remember that a DRC defines Database Roles, so all Databases within a DRC will Switchover/Failover together in case of emergency! If you would like to retain finer control over which databases switchover/failover independently of any others, you may create DRCs with only a single Database in them - having multiple DRCs per Instance is supported.

• File Transfer Address/Port: the Standby SQL Agent & Control Center communicate to each other via the Agent Communications Port (default 4222), but the actual Database backup files are sent between Agents directly via a separate, dedicated channel. This channel is defined by these two fields - make sure the Hosts can see each other on the addresses specified here, and the entered ports are open. Each DRC must have a different File Transfer Port - this will be improved soon to use a joint single port per Host plus include a connectivity test.

Usage

Once at least one DRC has been successfully created, you can begin using it to run Database Actions. To do so, click a DRC (a Start button will appear once you hover over it).

The Disaster Recovery Configuration Actions screen shows all the Actions that are possible for your selected DRC. Note that all options are either greyed-out or made available dynamically based on what the software has detected is possible at the current moment. For example, if your Standby Instance is empty (i.e. has no user databases), the only Action that will initially be available is the Create Standby Databases Action - all other Actions depend on the presence of at least one Standby database for the DRC.

Once you select any Action, you are presented with a Database Selection modal - select either one or multiple Databases to run the chosen Action on them.

As soon as a Database Action starts, you should be redirected back to the Dashboard view, where you will see the running Action represented as an Event on the right-hand side of the page under a new Events Timeline column. You can click on this Action for more details. All information, including Action progress, Instance States (indicated by the green/yellow wifi icons on the DRC) and the Time Gap between Primary & Standby is displayed in real-time.

Once an active Action finishes it turns either green (successful) or red (failed), with more information always available if clicked on.

Please note that to run the Switchover or Failover Actions, you will need to have a valid Standby Database for every Database in the DRC.

The Schedule Backups Action is currently unavailable - coming soon.

Related pages