Context: 

mirrored configuration with one primary member and one async member (without failover/backup member)

Purpose:

replace the CACHE.DAT of a mirrored database on the primary member.

I have setup an async reporting mirror member with Read only access.  My problem is that if I try to do any sql reporting against that data I am getting errors.  I am sure that this is because the DB is read only, but I had assumed that setting up a reporting mirror would handle this.

I there a setting or mapping  I am missing?

Hi all,

I'm using $ZUTIL(49) to get information of the databases I want to add to a mirror. This information is passed to  ##class(SYS.Mirror).CatchupDB(plstPathDatabases)  in order to Catchup all databases addes to a Mirror.

I know that ZUTIL is deprecated and I'd like to know what function or functions I have to use in order to get all necessary information for CatchupDB.

Thanks a lot

++Update: August 2, 2018

This article provides a reference architecture as a sample for providing robust performing and highly available applications based on InterSystems Technologies that are applicable to Caché, Ensemble, HealthShare, TrakCare, and associated embedded technologies such as DeepSee, iKnow, Zen and Zen Mojo.

Azure has two different deployment models for creating and working with resources: Azure Classic and Azure Resource Manager. The information detailed in this article is based on the Azure Resource Manager model (ARM).

Mirroring provides an admin capability to Stop Mirroring on this member, which causes a non-primary member to temporarily disconnect from the primary, stop dejournaling, etc.  While most system administrators may never need or use this function, some employ it for certain kinds of maintenance or other special cases.

The intent is that the administrator uses the Start Mirroring function when they wish the member to reconnect. However, today mirroring also implicitly restarts (reconnects) if the Caché instance restarts.

Good day, Cache developers and users!

At first, sorry for my bad English -)  I have a little question.

As I know, we can add database to mirror only on Primary Failover Node, using SMP or ^MIRROR. And the usual procedure after that is to copy mirrored database to Backup Failover Node and restore it there (by Backup restore or by Activate-Synchronize procedure). This all works fine. But what if I first have copied the database from Primary to Backup and only than added the database to mirror on Primary Failover Node? (human forgetfulness).

Does anyone know any sites who configure an async reporting member to connect to two different failover mirroring sets ?

I know this is supported, but I would like to know how it is working in real world systems.

Any information would be appreciated.

 

Presenter: Mark Bolinsky
Task: Provide failover for distributed systems without using a VIP
Approach: Demonstrate using InterSystems’ database mirroring with external traffic managers such as F5 LTM/GTM
 

With distributed environments and even public cloud environments, the use of a VIP sometimes is not desirable or even possible given network topology or deployment. The session will demonstrate integrating database mirroring with external traffic managers such F5 LTM/GTM using API based triggers in InterSystems products to interface with the F5 appliances. This not only presents automated redirection for the local mirror members, but also provided automated client redirection to asynchronous DR mirror members. 

Content related to this session, including slides, video and additional learning content can be found here.

Presenter: Ray Fucillo
Task: Provide high availability (HA) and disaster recovery (DR) in diverse architectures that demand high performance, including replication over long distances
Approach: Give examples of mirror architectures in disparate environments, including geographically separated systems. Discuss performance considerations and advances in InterSystems’ mirroring technology
 

In this session you will learn about deploying Mirroring to provide HA and DR in diverse architectures that demand high performance and throughput. Challenges and solutions to achieving high throughput will be covered along with mirror architectures that involve long distances and disparate environments.

Content related to this session, including slides, video and additional learning content can be found here.

Here are a few tips that might be useful to people who are running applications in an environment that's configured to use InterSystems mirroring.

• If you configure an ECP connection to a Caché instance that is a mirror member databases then the ECP connection should also have mirroring enabled (tick the mirroring box when defining the connection). More details here. You may also need to increase the number of ECP connections each end accepts, to cater for the way both members of a mirror pair get involved in ECP negotiation.

Hi,

Can a Cache Mirror be  used in the cloud ? (ie stand up a Primary and Backup member instances in a High Availability Cache Mirroring configuration) 

I'm investigating the validity of this configuration, because I was of the understanding that this may not possible due to these cloud servers not (typically) having fixed ip addresses, which interferes with the Virtual IP settings for the mirror set.

Is this correct, and if there are workarounds (like Load Balancing ?) can I have details on how this should be configured ?

Providing a reliable infrastructure for rapid, unattended, automated failover

Technology Overview

Traditional availability and replication solutions often require substantial capital investments in infrastructure, deployment, configuration, software licensing, and planning. Caché Database Mirroring (Mirroring) is designed to provide an economical solution for rapid, reliable, robust, automatic failover between two Caché systems, making mirroring the ideal automatic failover high-availability solution for the enterprise.

Providing a reliable infrastructure for rapid, unattended, automated failover

Technology Overview

Traditional availability and replication solutions often require substantial capital investments in infrastructure, deployment, configuration, software licensing, and planning. Caché Database Mirroring (Mirroring) is designed to provide an economical solution for rapid, reliable, robust, automatic failover between two Caché systems, making mirroring the ideal automatic failover high-availability solution for the enterprise.