Here are the advantages to having a trigger file process, instead of having each client server write its data directly to ME:
- You get a distributed architecture. If for some reason all the client servers can't access the ME server, you can give them different trigger file shares and then another copy process can pick up the files and copy them to a more suitable location, or you can now have a firewall rule (for example) opened up from that single location to the ME server. And you don't have to have another ME server to make this happen, so it saves you on SQL Server licensing and complexity.
- You get simple ME disaster recovery. Should something happen - say the ME server goes down, or the network segment goes down - you can easily switch the trigger file location to somewhere else so you don't miss any collections. This way when the ME server comes back up, you can change the trigger file share back to what it was on the client servers, and copy the files over for processing. This way you avoid having to do a full import of all the logs, and you don't have to have another ME repo server around as a backup.
- You can easily place your own files in the trigger file share. All you need to do is create them the same way the MR process does, and you can use it to create your own log file imports.
- You can roll your own. If you don't like the way the ME history process works, you're free to turn it off and write your own. You can have MR continue to write the trigger files, and you can create your own process to pick them up and deal with them however you like.
Executables
MRHistoryProcess.exe
This executable processes trigger files for the Minion Reindex log tables.The Minion Reindex process creates a single trigger file for this collection. MR writes the trigger file as soon as the reindex for a specific database completes - not after the reindex batch completes - so the data can be collected into ME for alerting. If the reindex fails, we try to give you the error message in the alert email itself; this collection is where that comes from. So the process writes the file for this collection before the entire MR process is finished.
Unlike the Minion Backup process, which has multiple processes that can occur after the backup completes, reindex doesn't have that issue. Therefore, we're able to just create a single trigger file for each database after it completes the reindex process and not worry about any further processes.
This trigger file is created right after the maintenance completes for each database to ensure that any errors can be reported to ME right away for alerting.
Trigger File Location
The trigger file location for this collection is in the same base folder as all the others by default, but can be moved anywhere you like. To change the location, simply change the MinionTriggerfile column in the Minion.IndexMaintSettingsDB table for Minion Reindex. You can't put each database's trigger file into a different location even though each database override row can carry a different value. The MR process only chooses the top 1 value it finds and uses that for all databases.
You could however use a different trigger file location for each server, but it's advised that you only do that if necessary. ME will process from all trigger file locations and the more locations it has to go through the longer the collection process will take.
Reasons to create another trigger file location could include:
1. Permissions for firewall issues between the client server and the trigger file server.
2. The trigger file server is overloaded and you need to split processing in order to all the servers processed in a timely manner. This could happen if you're processing trigger files for all 3 maintenance products and you have thousands of databases and are producing trigger files at a very high rate due to something like taking log backups every couple minutes. In this case, you may find it advantageous to split the backup process onto its own trigger file location and use a different app server to process the files into the ME database.