This KB article has some general info on how MID Servers are affected by Instance Clones, and some of the things you need to keep in mind.
Are MID Servers Cloned?
No. When a production instance is cloned over a sub-production instance, the production instance's MID Servers are not duplicated or copied, and the sub-production instance will not end up with the same MID Servers as production.
MID Server installations will always point to the same single instance url set in the config.xml file of that installation, regardless of whether that instance is now actually a copy of another instance.
You will need at least one MID Server installation for each instance. You can install multiple MID Servers on the same host server to accomplish this, so long as they have different MID Server names.
In order to be able to effectively test MID Server features in sub-production instances, it is recommended to mirror the production MID Server configurations and install the MID Servers within the same network environments.
The MID Server's login credential
After a clone has overwritten a target instance with a new configuration, data and even a different version, existing MID Servers for that target instance will still be trying to connect to it using the same username and password that was originally configured for the MID Server.
The user table in the instance will now be a copy of the source instance's user table, and so the MID Server may be trying to log in with a user that now doesn't exist in the instance or may have a different password.
To avoid this, the recommendation is to use the same username and password for MID Servers on all instances. Different MID Servers for different functions can have different passwords, but the MID Servers for a particular function (e.g. Discovery of a particular region/datacenter) would use the same username/password.
For more information, see: Active MID Server post-cloning credential issues
The Instance Credentials table
Prior to the New York release, clones would replace the Credentials table [discovery_credentials] with the records from the source of the clone. Since New York, this table is both Excluded and Preserved in the clone, so that the sub-production instance keeps the Credential records it used to have before the clone.
This table is used by Discovery/Service Mapping probes from the MID Server, but also some other recent integrations features that may not even use the MID Server.
Warning: There is a problem with Data Preserver code in the clone engine, where it doesn't automatically preserve all child tables of extended tables. This breaks the OOTB Preserver setting in New York for discovery_credentials, and also custom settings, leaving corrupt credential records on the target. For more information and a workaround, see:
KB0717208/PRB1305469 Excluding table-per-class (TPC) extended tables from a clone can cause orphaned Discovery Credentials with the 'Record not found' error when trying to open them
The MID Server's own records
A MID Server installation can only be used by one instance. Production MID Servers will remain pointing to production, and so any records for those MID Servers don't need to be copied, and so are excluded from the clone. MID Servers for the sub-production instance will still be pointing to that, so records for those MID Servers need preserving.
This includes related records such as Properties, Parameters, Clusters, Capabilities, IP Ranges, Applications, Issues and records for the MID Server Dashboard.
Warning: Prior to Madrid, there was a known problem which means this isn't done properly. Upgraded instances may also not get the fixed exclude/preserve lists, and may need fixing manually. For more information, see:
PRB1287729 / KB0688954 - The MID Server Exclude/Preserve Clone settings cause MID Server issues on the target
MID Server Properties is a difficult table, because some are for all MID Servers, but others are for specific MID Servers. A clone will delete and overwrite those records. Any specific MID Server with non-default MID Server Properties may need manually re-configuring after a clone,
There are some ecc_agent... tables which should never be excluded in clones, because they contain Code, which is also version specific. Excluding these can cause missing or mismatched code after a clone, and the MID Server won't work as expected.
- and others..
Records and settings that reference MID Servers
In settings of all features that use MID Servers, there are likely to be references to specific MID server Sys IDs. e.g.
- Discovery Schedules set to use specific MID Servers or MID Server Clusters
- Import Data Sources set to use specific MID Servers
- Credential records restricted to specific MID Servers
A lot of those settings will have been copied over with the clone, but the MID Servers won't exist on the target instance, and so many of those features will now not work or do something unexpected and need re-configuring to use the target instance's MID Servers.
Post-Clone Cleanup Scripts can be used to fix or prevent a lot of these settings after a clone. e.g.
KB0789119 A Post-Clone script to Deactivate and Cancel Discovery Schedules
It is possible to configure MID Servers to have the same sys_id as the production MID Servers. If the installations are on the same host server, the names need to be different, but the sys_ids can be the same. This process and the pros and cons are explained in more detail in:
KB0719301 How to manually Clone a MID Server so that you don't have to reconfigure all integrations features to use a different MID Server on the sub-prod instance after an Instance Clone
Warning: Prior to New York, Discovery Schedules set to specific production MID Servers may unexpectedly run after clones:
PRB1311068 / KB0788922 After a Clone, a Discovery Schedule for a Specific MID Server, which does not exist in the target instance and so is now a broken reference, will still run in a random MID Server
Clones that change the Version of the instance
After a clone, existing sub-prod MID Servers will suddenly find themselves communicating with a 'different' instance compared to the previous incarnation of that instance. It will still try to connect, and will then try to upgrade/downgrade to match the version the instance is now.
Upgrades should work, and plenty of regression testing is done every release to make sure it does.
However it is possible to have a situation when the instance ends up on an earlier version (e.g. a sub-prod instance is used for an upgrade test, and then cloned over again), and then the MID Server may have problems. A MID Server running a future version compared to the instance isn't going to be able to communicate with the instance properly using API and encryption/validation features that are only present in the future instance version.
In a Downgrade situation, especially between major versions, you are going to need to be prepared to manually re-install the MID Server. For more details of that repair process see:
KB0713557 How to manually Upgrade and/or Restore a MID server after a failed Upgrade