You should review your license agreement with your account team. Licenses are typically per-user (where a user at a different IP counts as a separate user), but there are also connection limits for each user (each 'job' is a new connection as long as it is still around), and exceeding them can cause one user/IP to consume many licenses. 

If creating processes is slow, it might be worth looking into using Job Servers. This is a pool of processes that wait to handle 'job' requests. 

This is likely an issue with the OS - it shouldn't take that long to create a new process. It might be worth gathering an OS-level trace of your process while you do this to narrow down where the time is spent. Depending on platform, the trace can be gathered with strace, truss, Windows process monitor, or others.

From the documentation: "The best strategies for backing up databases are external backup and online backup." External backup involves external scripts (examples are included in the documentation, but do not show actually taking the backup, as that is done by 3rd party technology). This is generally the best way to take backups. Online backups can be configured and run from within Caché. All the various backup strategies, and details about how to use them, are available here:

https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GCDI_b...

This is best to be handled by the WRC. Please contact support@intersystems.com and provide the full cconsole.log as well as the timing of your attempted startup and details of what you deleted, how, and when.

For what it's worth, my best hypothesis based on the snippets you provided is that you have custom startup code that isn't completing (possibly due to whatever you deleted), which is blocking startup from continuing.

Calling into IRIS won't work if the instance is hung, so the only way to detect that is something external to the instance. Take a look at 'iris qlist'. You can get more information from 'iris help qlist', but here are the basics:

Syntax:
        iris qlist
Description:
        Quick list InterSystems IRIS registry information for all instances, in a format suitable for parsing in command scripts.

To add to this, given that you're concerned with security and want to use TLS 1.2, you should strongly consider upgrading, as 2012.1.2 has a number of security issues that have been fixed over the years.

Are the two mirror members functioning as primary and backup? No members will even attempt to connect to the arbiter until you have a primary and an active backup (because that is the only situation where the arbiter is used). If you do have a primary and active backup, and they aren't connecting to the arbiter, I'd suggest contacting the WRC so that we can take a look at this with you.

Is the database journaled? Remote non-mirrored databases on mirrored ECP database servers can only be mounted read-write on the ECP application server (in this case the reporting async) if the database is NOT journaled on the database server. This is documented here: https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GHA_mi...

"Select the database you want to access over this ECP channel from the list of remote databases. You can select both mirrored databases (databases listed as :mirror:mirror_name:mirror_DB_name) and nonmirrored databases (databases listed as :ds:DB_name); only mirrored databases remain accessible to the application server in the event of mirror failover. When the data server is a failover member, mirrored databases are added as read-write, and nonmirrored databases are added as read-only, if journaled, or read-write, if not journaled; when the data server is a DR async member, all databases are added as read-only."

I don't know the answer to this, but since you haven't gotten any responses here, I'd suggest opening a case with the WRC so someone can investigate it fully. Please include the $zv string from both instances involved, as well as the location of the installation (as I suspect that is relevant to the problem you're seeing).

This isn't enough information to answer definitively, as we don't really know whether there is a limitation on the client side or the server side. You should check IRIS' messages.log file. My best guess is that the errors may be due to running out of licenses. Either way, I think it's worth engaging the WRC on this, as a lot of setup-specific information is going to be required to get to the bottom of it.

This is what reporting async members are for. You can run an archiving task on the async to move the data to another database (or different globals in the same database, however you want to do it), then purge the data on the primary. As long as the reporting process knows where to look for the data, you're all set.

All you need to do is shutdown the instance on the primary. This is documented here:

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GHA_mirror#GHA_mirror_set_autofail_outages_primary
 

If your Veeam backup is short enough (on the order of a few seconds), there's really no need to do this, but if it's on the order of minutes, not seconds, that may be a good plan.

There are 2 scenarios that cause a journal sync that you missed:

• A journal switch
• ##class(%SYS.Journal.System).Sync()

The real question is why is that a problem? There are quite a few things involved in shadowing:

1) Processes retrieving/writing journal files

2) Dejournal reader process which reads those files and queues up records for sets/kills into database

3) Dejournal worker process which actually does those sets/kills

4) Dejournal prefetchers which fetch blocks from disk so 3) doesn't need to do disk reads itself

Most likely, you have 16+ dejournal prefetchers, optimizing the performance of shadowing keeping up with your source system.

It might be best to open a WRC issue for this, but this is a fairly common error message that actually has nothing to do with SSL. This is generally a sign of 1 of 2 problems, depending on your platform:

Unix: Incorrect permissions on the cuxagent binary on the PRIMARY mirror member. The permissions on that file should look like:

[root@RH7-64-001 bin]# ls -l /intersystems/CACHE/bin/cuxagent
-r-sr-x--- 1 root iscagent 27468 Sep 13 13:40 /intersystems/CACHE/bin/cuxagent

Windows: Generally a problem with the ISCAgent being unable to actually find the instance or access the cache.cpf file. If you look in C:\Windows\system32\iscagent.log, you should see the reason for the problem.

If this doesn't point you to the solution, I definitely suggest contacting support. 

I'd suggest taking a look at this documentation. It should be exactly what you need.

The short answer is that you cannot restore a CBK from AIX (a big-endian system) onto Windows (a little-endian system). You would need to restore the CBK on another location on AIX (or another big-endian system), and copy the CACHE.DAT to the Windows system, where you can run the cvendian utility to convert the endianness. Note that this comes directly from that page of documentation:

Note:

This utility does not work for backup and journal files. You must restore databases on a platform of the same endian, move the restored databases to the different endian platform, and then use the cvendian utility to convert the databases.

First, when you say you "loaded" 2017.2 onto your machine, did you do an install or something else? 

It sounds like you have a corrupt Windows registry. If you didn't do a full installation and just copied files onto the machine, that would certainly have caused this.

If you did do an installation, I'd suggest contacting the WRC, as this should never happen, and we'd like to get to the bottom of it.  We'll definitely want to look at the cconsole.log and the installation log (in C:\Windows\).

The best place to start would be our learning portal. There is an InterSystems IRIS learning track, and it has videos and courses that include sandboxes.