New post
AllAccepted answers
Pete Greskoff · Jul 17, 2017

I just want to add to this some other benefits of the way the data is stored. The first access of a global will have to read the pointer tree to find the particular node. A subsequent access of another node in the same global would only need to read from disk at the point where that node diverges in the pointer tree from the first. Even if the data blocks are not the same, a 2nd global access would likely be faster, since some of the tree would be cached, so fewer disk reads would be necessary.

Pete Greskoff · Jun 20, 2017

As far as ECP is concerned, you are only creating remote DATABASES. You can map 1 NAMESPACE on a system to point to any databases it has configured, local or remote. You could easily have app server instance A connect to both data server instances B and C and create a remote database for each of them. You could then have 1 namespace on A use the databases from B and C for various things (globals, routines, specific mappings).

Pete Greskoff · Apr 24, 2017

You can also do this via ^SECURITY

%SYS>d ^SECURITY
 
1) User setup
2) Role setup
3) Service setup
4) Resource setup
5) Application setup
6) Auditing setup
7) Domain setup
8) SSL configuration setup
9) Mobile phone service provider setup
10) OpenAM Identity Services setup
11) Encryption key setup
12) System parameter setup
13) X509 User setup
14) Exit
 
Option? 12
 
1) Edit system options
2) Edit authentication options

Pete Greskoff · Apr 21, 2017

In each production component, there should be a setting for "Local Interface" that allows you to control the interface. If you have a separate interface for the VIP vs. the machine IP, it will work. If they use the same interface, there's no way to control it.

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ETCP_settings_inbound#ETCP_LocalInterface

Pete Greskoff · Mar 30, 2017

There is one extra piece to this that you might want to look at, and that is the GetReason() classmethod of %SYS.Journal.File. It will tell you "by backup" if the file was switched by ExternalFreeze. The following code will search back from the current file and print out the file name of the journal file that was switched to for the most recent ExternalFreeze or Caché online backup (there is no error checking, so it could fail if you don't have any files created that way):

s file = ##class(%SYS.Journal.System).GetCurrentFile()
s reason = ""
f {
s reason = file.GetReason(file.Name)
q:reason="by backup"
d ##class(%SYS.Journal.File).GetPrev(file.Name,.name)
s file = ##class(%SYS.Journal.File).%OpenId(name)
}
w file.Name
Pete Greskoff · Mar 29, 2017

Again, I suggest opening a WRC issue to address this. The first step will likely be to enable REDEBUG (do ^REDEBUG in %SYS and set the new value to FFFFFFFF). Then you will disconnect from the mirror (^MIRROR -> Mirror Management -> Disconnect), then connect again. Then set REDEBUG back to FF and collect the cconsole.log for the WRC as well as the cconsole.log on the primary. I must ask again if you added the async as an authorized async on the primary, as that is required to connect if using SSL.