New post
AllAccepted answers
Bob Binstock · Oct 25, 2016

Yes, that's correct. The ISCAgent should be running on the backup member at all times. The "Application Considerations" section of the Using Veritas Cluster Server for Linux with Caché appendix  of the High Availability Guide 
(http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_veritas_clusters#GHA_veritas_clusters_app_considerations) says:

  • If any Caché instance that is part of a failover cluster is to be added to a Caché mirror, the ISCAgent, which is installed with Caché, must be properly configured; see Configuring the ISCAgent in the “Mirroring” chapter of this guide for more information. For any node on which Caché was not installed as part of cluster setup (see Installing a Single Instance of Caché), install the ISCAgent on that node (see Installing the Arbiter in the “Mirroring” chapter for information about using a standalone ISCAgent install kit for this purpose) and then configure it.

We had a discussion about this some time back and concluded there is no reason not to have the agent running at all times on all mirror members regardless of their status in the cluster.

Anzelem, maybe I should move this up into the "Install a SIngle Instance of Caché" procedures in all the cluster appendixes?

Bob Binstock · Oct 20, 2016

Jared, I'm not sure what you mean by "an async mirror over a shadow configuration". A reporting async in a mirror has similarities to a shadow but is not the same thing. The minimum downtime upgrade procedures for mirrors that you cited don't involve any shadow configurations, and in fact the "minimum downtime" aspect depends on mirror failover, which is something a shadow cannot do. As I noted, this is a clear advantage of mirroring over shadowing.

You are correct that, as I noted, mirroring provides the option of DR async promotion, which provides superior disaster recovery to shadow-based DR. But I want to clarify that DR asyncs can be and are often "off-site", that is, at a geographical remove from the primary data center. They fulfill this need as well as a shadow does and provide the added benefit of promotion.

Bob Binstock · Sep 27, 2016

Wolf, you can certainly set up a mirror consisting of one failover member and a reporting async member.

Mirror management and the mirroring user interface are at this point considerably better developed than the equivalent for shadowing. As someone who has been through the procedures for setting up and managing mirrors and shadows, I would certainly opt for the former for usability and monitoring advantages if nothing else.

Mirroring has capabilities that make planned maintenance easier; you don't have to maintain a second failover member or DR async, but you can add one to serve as temporary primary when you want to bring the primary down for maintenance or do a minimal downtime upgrade. In addition, having a mirror allows you to easily add capabilities in the future. For example, you can add a DR async for disaster recovery that is superior to what shadowing or a reporting async provides (since a DR async can be easily promoted to primary) or convert your reporting async to a DR async. You can also add reporting asyncs as your query needs evolve.

Perhaps someone with more expertise regarding the architectural advantages mirroring may have over shadowing in this setup can elaborate on those.

Bob Binstock · Sep 23, 2016

While there is certainly no harm in following the procedure Mike describes, InterSystems recommends consulting the documentation (in this case http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCI_windows) before and during your Caché install, especially if you plan to keep the Caché instance around for specific purposes. For example, understanding the implications of choosing a security level, of 8-bit vs unicode, of whether to run Caché under the local system account or under other credentials, and so on before making these decisions is very useful. And having the background information provided is generally helpful in understanding and working with Caché.

All of the latest Caché and Ensemble documentation is always available at http://docs.intersystems.com, and by using the Search function here on Developer Community as well.

Bob Binstock · Sep 22, 2016

All Caché and Ensemble documentation is also accessible using the Search function right here on Developer Community. By using the Categories filter, you can quickly find a useful entry point into the documentation, and then browse around and search within it if need be. 

For example, if I search for "Cache SQL" and then set Categories to Product Documentation and scroll down a bit, I find Caché QuickStart Tutorial  ▶  Querying the Database and a little later many links into the Caché SQL Reference, for example Caché SQL Reference  ▶  SELECT. Needless to say, searching "Cache SQL Reference" narrows it down quite a lot.

Clicking the title of a search result gives you a Developer Community display of the material, but clicking the View the related documentation link for any entry takes you into the documentation itself. 

Note that the search filters can also be used to narrow searches for a lot of other useful things. For example, try searching Ensemble with Categories set to Video and Tags set to Ensemble for a long list of very interesting Ensemble-related videos. (You can choose tags within the Ensemble group to narrow it down.)

Finally, about the "beta documentation" Mike refers to:  

Bob Binstock · Sep 8, 2016

Kevin, see  http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=.... The failover members are not required to be running the same operating system; as long as they have the same endianness and the Caché instances are of the same version and have the same character width and locale, the mirror will work.

Remember, however, that there is no defined primary. As the article notes, "Since the failover members can trade roles as primary and backup at any time, they should be as similar as possible; CPU and memory configuration should be the same or close, and the storage subsystems should be comparable." I would extend this to Alexey's point about applications. As long as the two machines will operate exactly the same way in response to application connections to the databases, handle the same loads, and so on, you are OK.

Bob Binstock · Jul 26, 2016

i agree, Mike, i wouldn't discourage anyone from just trying it out. but even the simplest installation of Caché presents choices that have lots of significant implications, for example 8-bit vs. unicode and security settings. it doesn't add a lot of overhead to have the documentation open so you can read along with the procedure as you execute it, and at the least it may save you the trouble of having to uninstall and start over again.

Bob Binstock · Jul 25, 2016

While this overview is accurate and helpful, I strongly recommend consulting the Caché Installation Guide before beginning the installation process, and having it at hand while installing.

There are a number of things to consider for each platform (Windows, OpenVMS, UNIX®/Linux, and Mac) before you install; the install guide covers general preparation in the chapter for each platform, and also includes appendixes on system parameters for OpenVMS and UNIX®/Linux, preparing for Caché security, and file system and storage recommendations. (There is also a chapter on upgrading Caché.)

There are also a lot of options to choose among during the installation process and it useful to have the explanations available when deciding.

Finally, the install guide offers alternatives to interactive installation, including unattended installation on Windows and on UNIX®/Linux systems and the use of the %Installer class with an installation manifest.

OpenVMS note: the SET FILE/ATTRIB command cited by Richard, which may be necessary to restore to the install package attributes that were stripped when it was conveyed to the target system, was recently updated, as follows:

$ SET file/attrib=(rfm:var,mrs:32256,lrl=32256,rat=none) cache-2016.1.0.657.0-alphavms.bck