I have a few questions:

1) Why exactly do you need to call these via REST? What scenario do you have where running something like the example code in the documentation wouldn't work for you?

2) Assuming you do have a good reason to make these calls via REST, which part do you need help with? Creating the REST endpoint? Making the REST request?  Writing the code on the back end to run the appropriate commands?

You probably want to check out this Global Summit presentation from this year. The entire presentation is useful, but you might want to skip ahead to slide 70 for your purposes.

I'll tackle question 2:

For deciding which backups to take in an ECP environment, it really depends on your setup. In a somewhat typical setup, you'd have the data on the database server, and code on the application servers. In that case, you would definitely want to back up the database server (since that's where the data is), but you may not need to back up the application servers if you have some other repository (such as source control) for your code base. 

I am not quite sure what you mean by having multiple data servers with the same instance name and database name. Can you elaborate? It is certainly possible to mirror your database server in an ECP environment.

Finally, I just want to note that you are talking about sharding, but tagged this as a Caché post. Only InterSystems IRIS supports sharding, not Caché. You probably want to tag this post with IRIS instead of Caché (or both, as your 2 questions really are quite separate).

There are no built-in REST APIs to call the API's, but you could easily write one.

All the methods to retrieve the list and add/remove databases from the list are documented in the Backup.General class here. As John mentioned, there is no way to freeze or thaw individual databases; it is a system-wide operation.

There are a few good suggestions here, and I just want to add another one. You could write custom code as a wrapper to call API's for whatever you're changing (whether adding users, tasks, etc.). Then, on all mirror members, you could configure a REST service that would accept requests to do the same (aka call your wrappers based on the request payload). Then, when you call a wrapper to, for instance, add a user, your code would call the REST service on the other mirror members, which would trigger adding that user on those members, and call the Security.Users Create method to add the user on the local instance.

From what I've gathered from Oracle, CDC is just a way to replicate data onto another system. If that's what you're looking for, Caché mirroring is the answer you're looking for. Take a look at:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

That's the general mirroring information for how it works. Contained in that chapter is information about reporting asyncs, which is what it sounds like Oracle's CDC is for:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Though, it looks like Oracle replicates data to a different database on the same system, which mirroring will not allow. If you want to do replication to a different database on the same instance (though I can't think of a use case for that), you could use shadowing instead:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

You can assign a custom resource to the Message Viewer, per this documentation. See screenshot below (the assign button). You'd just need to make sure users that actually need to be able to use the message viewer have access to whatever custom resource you assign. There's also more information about the Ensemble Management Portal security in general in this documentation, which might help.

It is definitely worth pursuing if you want to use it. Contact the WRC and give us the version you're using as well as the output from the failed install, and we'll be happy to help. FWIW, I've set it up on Windows and gotten it to work, but not on Mac. 

I don't see anything recently suggesting a similar problem or any changes in the product (though I may have missed something). I suggest filing a WRC issue for this for a more detailed investigation, but I'll give you my best guess here:

I suspect you typically start/stop the instance as a user that is not an Administrator. When you did the upgrade, you did so as an Administrator, and that left the instance running, started by an Administrator. The difference in which user started the instance likely caused the problem shutting down as another user. Given that, I'd expect that subsequent startups as a non-Admin user would allow for shutdowns also as a non-Admin user.

If this isn't the case, please provide the cconsole.log and the Caché SYSLOG ('do ^SYSLOG' from the %SYS namespace) to the WRC, and we'll be happy to help.

I suspect that the database has 2 KB block size. It would be mountable in 2008, but not in 2014. If you still have access to the 2008 system, you can run GBLOCKCOPY to convert the database to 8 KB blocks.

You should definitely contact the WRC about this. We will definitely want to look at your cconsole.log file. My best guess without much information is that a Caché process died abnormally (was killed at the OS level, or some other way that it wouldn't go through Caché halt codes) while holding onto the resource that controls access to the PID table. This basically prevents any new processes from being created. 

You'll likely need to run 'ccontrol force cache' to get the system down, but please collect a CacheHung report beforehand (a script in the /bin directory of the instance) to provide to the WRC.

These messages generally mean that a process is trying to run a routine as it is re-compiled, and the kernel realizes that the routine has changed out from under it. They don't necessarily indicate a problem, hence the informational 'level-0' message.

I think this is a better question for support. I recommend opening a WRC issue for this.

You want to use the condition parameter of zbreak. Take a look at this code:

zTestDebug
s x(1,2,3) = -2
s x(1,2,3) = 1
s x(1,2,3) = 3

If I do the following with zbreak:

zb *x:"B":"$g(x(1,2,3))>0"

This just breaks if x(1,2,3) is greater than 0. Then execute the routine, this is what happens:

%SYS>d ^zTestDebug
 s x(1,2,3) = 1
 ^
<BREAK>zTestDebug+2^zTestDebug
%SYS 2d0>g
 s x(1,2,3) = 3
 ^
<BREAK>zTestDebug+3^zTestDebug
%SYS 2d0>g
%SYS>

You can add an argument to $zf(-2) such that the child PID is returned in $ZCHILD. This is documented here. For reference:

s rc=$zf(-2,"program","","",1) 
s childpid=$ZCHILD 

Security.Users Export method is what you need. It does allow you to specify usernames or roles to export. From the docs:

 classmethod Export(FileName As %String = "UsersExport.xml", ByRef NumExported As %Integer = 0, Usernames As %String = "*", Roles As %String = "*", SQLPrivileges As %Boolean = 0, ByRef NumSQLPrivilegesExported As %Integer)as %Status

This method exports User records to a file in xml format.
Parameters:
Filename - Output file name
NumExported (byref) - Returns number of records exported.
Usernames - Comma separated list of Usernames to export, "*" = All
Roles - Comma separated list of Roles, "*" = All. Export Users containing only these roles
SQLPrivileges - 1/0 flag. If 1, export all SQL Privileges from all namespace on this system that have been directly granted to this Role
NumSQLPrivilegesExported *byref) - Returns number of SQL Privileges and SQL Admin Privilege Set records exported

I'm a bit confused by this question. When a failover happens, all the connections to the instance will be forcibly shut down, since the instance will be forced down. 

If you want to do anything to start things up at a specific point in the process of the other node becoming primary, you can put code in ZMIRROR.

Anything launched by $zf(-1) is going to run as the user that is running the original process. In the case of a Caché terminal session, that will just run as whatever user is running the terminal, and there's no way to get around that. 

If you were to use another method to run the $zf command, such as a Telnet connection, or running it via the Caché task manager, the process would instead run as the user who owns the Caché Controller services. So, if you REALLY need to be able to run cmd as an administrator, the best way would be to make the user who owns Caché  the system administrator user, and then run this code via the task manager (you could use a RunLegacyTask).

All that said, I have to agree with Rubens, this is not an ideal setup for security reasons, why can't you just make it such that your executable will run without the need for administrator access? Is there a particular reason why it requires administrator rights?

If you are using the Cube's terminal, you can define a connection (Preferred Server -> Add/Edit) that points to the VIP (assuming that the 2 mirrored instances are using all the same ports). You could then make that the preferred server (Preferred Server -> click on that connection). Then the default behavior for that cube's terminal would be to connect to the VIP address.

However, if you are trying to run scripts on only the primary server, you may want to look into using task manager. You can define tasks to run only on the primary mirror member. You could have the task call out to the script on both instances, and it will simply not run the task if the instance isn't primary.

The concept of a relay server was something built into the original design for mirroring. It was never fully implemented, hence the lack of documentation. There is no way to use a relay server.