Contents
This document explains how to configure LiveView Desktop to automatically reconnect to one or more failover servers in the event the primary LiveView Server becomes unavailable.
You can configure LiveView Desktop to automatically reconnect to one or more failover servers in the event the primary LiveView Server becomes unavailable. The failover LiveView servers must be running a compatible LiveView release and a compatible LiveView application that has the same table names and schemas.
Connecting to a failover server is not attempted unless your initial connection to your primary server succeeds. That is, you must be connected at least once to your primary server before the failover mechanism becomes available.
The Connect to LiveView dialog contains a new section, Failover Servers. If your site's LiveView server configuration does not include any failover servers, you can keep the new section of the dialog closed, and connecting to your single LiveView Server works as before.
|
To run a cluster of LiveView failover servers, you must have:
-
A primary LiveView server.
-
At least one failover server, which must:
-
Have a release of the StreamBase and LiveView Data Mart software that is compatible with the release of LiveView Desktop you are using, as defined in the Compatibility Concerns section of the LiveView New and Noteworthy document. The best practice is to have primary and failover servers both running releases with the same two-digit
major.minornumber (such as StreamBase 7.4 and LiveView 1.6), but other combinations may work, as described in Compatibility Concerns. -
Be currently running a substantially similar LiveView application, one that has the same tables, with the same table names and schemas.
-
For testing and evaluation, you can configure two or more LiveView server instances on the same host computer by editing their Run Configuration entries to specify different ports for each instance of StreamBase Server, and the same for each instance of LiveView Server. The examples on this page were taken from one physical server, argyll, with three LiveView Server instances running on ports 10080, 10090, and 10100. The corresponding StreamBase servers were configured to run on ports 10001, 10002, and 10003, respectively.
When the above conditions for a LiveView failover cluster are met, configure LiveView Desktop for automatic failover with the following steps:
-
Open the Failover Servers section of the Connect to LiveView dialog.
-
Click the button. This opens an empty line in the Failover Servers edit list, with placeholder text
failover server URI. -
Click to edit the newly added line. Replace the placeholder text with LiveView Server URI of your first failover server. You only need to specify the server name (or IP address), if the LiveView Server runs on the default port, 10080; otherwise, provide a server name and a port number. You can also specify a fully qualified LiveView server URI in the format
lv://servername:portnum. Press Enter to complete the entry.To edit the URI to correct errors, click in the line of interest, make your corrections, then press Enter to exit edit mode. Notice that the , , and buttons are only active when you select the full line for a server's URI, not its text. Those buttons are unavailable while you are editing any line.
-
Leave the Timeout check box selected, and specify the number of seconds you want to wait between failover connection attempts, or leave the default value of 15 seconds.
The Timeout check box specifies whether a timeout period applies to any reconnection attempt after the first. That is, no timeout ever applies to the initial connection attempt to the primary server; that connection must succeed or fail.
Best practice is to leave the check box selected so that each reconnection attempt fails over to the next server in the list. The primary server is automatically placed at the end of the list of failover servers so that if a connection attempt to the last failover server in the list times out, the primary server is automatically retried, and so on, cycling through the list again.
Clear the Timeout check box only if you need to manually control which server to try next, using the and buttons described in Interrupting a Reconnection.
The following dialog fragment shows LiveView Desktop configured to connect to a primary LiveView server running on server argyll on port 10080 (the port number is not shown when it is the LiveView default port, 10080). Failover servers are expected to be running on argyll at ports 10090 and 10100.
|
Remember that LiveView Desktop does not start
your failover servers for you. It can only connect to servers that are already
running and past their log announcement that LiveView is ready
to accept client connections. Be sure to start your primary and failover
server instances independently of LiveView Desktop.
When you click the button in the Connect to LiveView dialog, Desktop attempts to connect to the URI of the primary server specified in the Server field. You must specify a valid LiveView URI for a primary server in order to use the failover feature. On its initial connection attempt, LiveView Desktop always tries to connect to the primary server first, and that connection must succeed or fail.
No timeout period applies to the initial connection attempt to the primary server. If, for the initial connection, the primary server is up and accepting connections, your LiveView Desktop session begins immediately.
If, for the initial connection, the primary server is down or not accepting connections, the green slider on the Connecting to control continues its left and right motion indefinitely until either the primary server finishes initializing and becomes available, or you click the red Stop button. In the first case, Desktop connects automatically to the now-available server. In the second case, see Interrupting a Reconnection below for the actions you can take after clicking the Stop Interrupting a Reconnection button.
After an initial successful connection, if a running primary LiveView server stops responding, LiveView Desktop shows a line like the following in its status bar, then opens the Connect to Server dialog to attempt a connection to the next failover server in the list. If all goes well, with fast servers and an uncluttered network, connecting to the next failover server can occur so quickly that there is no time to show the dialog.
|
After a default 15 seconds of trying, LiveView Desktop tries to connect to the second failover server in the list, if present. When connections to all failover servers have been attempted for the default 15 seconds each, Desktop tries the primary server again. Connection attempts continue to cycle in sequence until a server responds and allows the connection, or until you interrupt the cycle with the button.
|
You can interrupt any reconnection attempt by clicking the red Stop button, shown highlighted in the Connect to Server dialog image below.
|
Once the Stop button is invoked, the Connecting to bar at the bottom of the dialog clears, and the and buttons become active.
|
Use these buttons as follows:
- Connect Button
-
Use this button to restart a paused reconnection cycle. (You can do the same using the → menu item shown below.)
- Skip Button
-
Use this button to skip the current reconnection attempt in the list of failover servers, and try connecting to the next server in the list. Use when you know that one or more failover servers are down, to bypass the default 15 second timeout period.
When you get to the end of the list of failover servers, the next entry is always
(cycle, starting with the primary server URI again). Skip onto that entry to have another set of primary plus failover URIs placed in the list to skip through or reconnect to.
- What happens to my server-stored Desktop workspace when I connect to a failover server?
-
When you make your initial connection to the primary LiveView server, you may have downloaded a server-stored Desktop workspace, which was copied to your local file system. Once the server-stored workspace is copied locally, you continue to use that local workspace through successive connections to failover servers. A new copy of the server-stored workspace is never re-downloaded by a reconnection.
- How do I tell if I'm still connected?
-
If your live data views are not updating, there are two ways to tell if you are still connected to LiveView Server. One is to look in LiveView Desktop's lower right corner, which reports either or Not Connected. The second is to open the menu; if is dimmed, you are still connected.
- How do I tell which server I'm now connected to?
-
You might have lost track of which primary or failover server you're connected to, if you have had to cycle through many recent reconnections. If your primary and failover servers are compatible, then it should not matter which one is current. However, your site's IT department might, for example, issue a request for all users to disconnect from server A and reconnect to server B. To find out if you're currently on server A, hover the mouse over the Connected label in Desktop's lower right corner. The hover pop-up text shows the release number of the LiveView server instance you're connected to, the fully qualified URI of that server, and the username you signed in with.
- Shouldn't I add the primary server's URI to the list of failover servers?
-
LiveView Desktop automatically cycles among one primary server and one or more failover servers, so there is no need to explicitly declare the primary server as a failover server.
However, you might want to add the primary server one or more times in the failover server list to force more connection retries to the primary server. For example, with two failover servers, the following configuration guarantees that a connection to the primary server is tried every other reconnection attempt:
Primary Server: A Failover Server: B Failover Server: A Failover Server: C (back to primary) - Is my reconnection attempt history stored?
-
Yes and no. The Connect to Server dialog, shown in examples above, does include a Server Connection History grid that shows the local time and date for the last few reconnection attempts. However, this dialog does not preserve the history shown between invocations, so the History grid shows only what has occurred since LiveView Desktop was last started.