InterSystems Database Mirroring. Creating and testing mirrors. Part 1

    About technology


    Caché Database Mirroring appeared in InterSystems Caché and Ensemble in 2010.
    The technology allows providing information systems (IS) built on Caché and Ensemble with the FAILOVER option - the ability to overcome some malfunctioning states of a DBMS, operating system or hardware.
    Why does the information system need failover - a long- studied issue , but in a nutshell, failover minimizes the downtime of users in the event of malfunctions leading to a denial of service for the server with the information system.

    InterSystems Database Mirroring can be synchronous and asynchronous. Synchronized allows you to create highr availability solutions for Caché and Ensemble systems. Asynchronous solves the problem of building disaster-resistant solutions by backing up data to geographically dispersed servers.
    Details on the characteristics of the InterSystems Database Mirroring solution can be found in this document . This article is devoted to setting up a synchronous mirror “from scratch”, reproducing failure scenarios and “experienced tips” on operating systems with Mirroring.

    Synchronous Mirroring. How it works?


    To use Mirroring, you must create a bunch of two separate Caché servers. One of the servers is Primary, and users of the information system work with it. The second is a Backup server, which has an actual copy of the Primary server data and is waiting for its failure, ready to become a Primary server and continue to serve IP users.

    In order for the servers and mirror participants to always know about each other's status, the ISC Agent service is used, which constantly works on each of the servers.

    It is convenient to assign a virtual IP (VIP) for the mirror, with which the clients of the information system work: ECP clients, application servers, JDBC / ODBC connections, terminals, etc.

    During regular mirror operation, clients work through the VIP with a Primary server, changes to Primary are collected in a log, which is played online by the Backup server.

    Failover situation development

    Consider a failover scenario.
    1. Primary server stops due to a failure or as planned.
    2. The backup server through the ISC Agent “understands” that the Primary server is no longer working.
    3. The backup server becomes Primary.
    4. IP and ECP clients connect via the same VIP to a new Primary server with minimal delay.
    5. The former Primary server is placed in the Backup server state.

    Synchronous Mirroring. Benefit?


    Synchronous Mirroring eliminates or reduces downtime of an information system in the event of a failure.
    In addition, this solution will allow administrators to carry out scheduled maintenance of the information system without interruption in user work. All scheduled work can be performed on the Backup server, while Primary serves the clients. Work examples:
    • OS update
    • Caché / Ensemble update,
    • execution of backup procedures
    • repair / upgrade of iron.

    After that, we make the Backup server primary, and for the former primary, which has become the new backup, we perform the same list of scheduled jobs.

    Creating a mirror from scratch


    Configuration

    The mirror is two cars with a Caché / Ensemble. In our case, two virtual machines Failover1 and Failover2 were created with Windows 8 and Caché 2012.2.RC on board.
    To create a mirror, servers must also have the Multi-server option in the license settings.
    Enabling ISC Agent

    image
    First of all, on both servers you need to enable the ISC Agent service. The service should work in the “auto” mode, and also have the option to automatically restart. On a Windows machine, the ISC Agent service is configured in Administration / Services. In Linux, we start the script to start / stop

    /etc/init.d/ISCAgent start    // для старта
    /etc/init.d/ISCAgent stop    // для останова
    


    Primary server setup

    image
    On the Failover1 machine, go to the Caché / Ensemble Management Portal in the Administration / Configuration / Mirror Settings section, select Create Mirror.
    image
    For the mirror, determine the name, virtual IP (VIP) address. It is recommended to organize communication between servers via SSL / TLS connection, as through it the data of the information system in unencrypted form will be transmitted. If the addresses in the server subnet are distributed via DHCP, we exclude VIP from the addresses to be distributed.
    We set the name of the Primary server in the Caché configuration name / name format (here FAILOVER1 / CACHE) and the agent port (default is 2188).
    Additional settings

    Quality of Service Timeout (QoS timeout) - the timeout after which the Primary server considers the Backup server to be “down” and the Backup server begins to find out if the Primary server is really working.
    Acknowledgment mode - received / commited. It affects the data log synchronization logic: write as soon as the data is received, or take into account transactions. received (write immediately) - by default.
    Agent Contact Required for Failover Configuration (Agent Contact Required for Failover) - yes / no. A parameter that determines whether a functioning ISC Agent is required for an automatic FAILOVER operation. Next, we will discuss the scenarios separately for various values ​​of this important parameter. The default is yes.

    Configure Backup Server

    image
    Go to the Failover2 virtual machine, launch the Control Panel / Administrative Tools - select the option “Connect as Failover”.

    image
    We specify the Primary server, the ISC Agent port and the name of the Cache configuration on the Primary server. We connect the servers.

    image
    After that, we go again to the first server, and add the Backup server to the mirror settings.

    image
    Connect - and verify that the mirror is working. The mirror status can be viewed in the System Operation / Mirror Monitor tab.

    Including a database in the mirror

    image
    The next configuration step is to include the database with which the information system works in the mirror. This is what the mirror itself serves to synchronize databases between two servers. We have created an ASU database in the Caché system, which we will mirror. You can select any local database, for example, a pre-installed USER database or create a database with the name ASU too.
    Put the database in the mirror on the Primary server.
    image
    Next, we perform a full backup of the database. On the Backup server, we restore data from the terminal in the% SYS area using the ^ BACKUP program or any other database recovery utility .
    image

    image
    In this case, the database will be immediately included in the mirror on the Backup server, as information on mirror ownership is already contained in the backup.
    After restoring the backup, the database must be activated (Activate) and brought up to date with the primary server (catch-up). We go into the Mirror Monitor of the Backup server and run it for the Activate and Catch-up databases.

    image
    The database is included in the mirroring and is ready to work - this can be seen on the mirror monitor.

    image
    Connect via the virtual IP address of the mirror to the web application that is installed in the ASU database. Make sure the application works.
    Total

    Now everything is ready, you can destroy the test server to test the functionality of the mirror. But more about that in the next part. To be continued ...

    Also popular now: