Transaction Server and Logging Configuration

Use the configuration questions in create_config.py to configure Transaction Server and system logging behavior.

System and Transaction Log Configuration Parameters lists the information required to configure the system log and transaction logs.

Table 1. System and Transaction Log Configuration Parameters
Parameter	Description	Default Value
System Log Level	The global log level used for logging MATRIXX Engine information. The default log level is set to `info` so critical, error, warning, and general information messages are written to the system log. If you set the log level higher than `info`, the same information is written to the mtx_debug.log file with the addition of debug messages. The possible log levels, in order of more verbose information, are: `off` `critical` `error` `warning` `info` `debug` Important: The log level must be set to `info` at a minimum to allow for troubleshooting issues. Note: You can dynamically change this log level during runtime to enable more intensive logging that includes `debug` and `trace` messages. `What log level do you want to use?`	info
Transaction Log Format	The following log formats are listed in order of impact, from least system-intensive to highest system-intensive. none — Logs are not generated. Only use this option when running a test system. text — Writes logs asynchronously in compact MDC printed format. xml — This format is the most system-intensive. Logs in XML format take longer to write and take up more disk space than the logs written in other formats. text_sync — Writes logs synchronously in compact MDC printed format. This option requires more overhead to generate the log because transaction processing is halted until the operation is complete. This is the default. text format might be faster than binary format if the MDC has a lot of unused fields because the size of the text data is much smaller than binary data. `Do you want to use the default log formats and log file names (y/n)?y`	text_sync
Transaction Log Filename	Transaction logs are named transaction_log_%y_%m_%d_%p_%t_%s.log, where %y_%m_%d_%p_%t_%s add the following information to the file: %y_%m_%d — Year, month, and day the log was created. %p_%t — Transaction Server process ID and thread ID. %s — An increasing sequence number. The checkpoint task relies on the log file names to determine which transaction logs must be replayed to update the database. The default value must not be changed in a production environment. `Do you want to use the default log formats and log file names (y/n)?` Note: If the `gtc_sorted_txn_logging_enabled` parameter is enabled, the transaction log filename is in the format txn_<log_create_time><min_gtc><max_gtc>.log.	transaction_log_%y_%m_%d_%p_%t_%s.log
Transaction Logging Characteristics	Transaction logs are created with the following default characteristics that you can change by answering no (n) to the question `TransactionServer:Do you want to use the default transaction logging characteristics (y/n)?` The compression Level is 5, where - 0 is none, 1 is the fastest, and 9 is the smallest. `TransactionServer:What compression level do you want to use for the transaction logs?` The batch write size in KB is 1024, where 0 is disabled. `TransactionServer:What is the size in KBytes that you want to use to trigger a batch write for a transaction log?` The batch write size in milliseconds is 50, where 0 is disabled. `TransactionServer:What is the time in milliseconds that you want to use to trigger a batch write for a transaction log?00` The trigger for closing a transaction log can be either the configured batch size or time exceeded. The default size is 1000 MB and the default time is 30 seconds. `TransactionServer:What is the size in MBytes that you want to use to trigger a file close for a transaction log?` `TransactionServer:What is the time in seconds that you want to use to trigger a file close for a transaction log?` The idle time elapsed after which a transaction log is closed. The default is 60000 milliseconds, and a value of 0 does not close the log when it is idle. `TransactionServer:What is the idle time in milliseconds that you want to use to trigger a file close for a transaction log?` The default number of write buffers to use during transaction logging is 200. If using an async write format, use 1 write buffer. `TransactionServer:How many write buffers do you want to use for transaction logging?` The number of threads to use when writing the transaction logs. Each processing server does shadow logging for the other processing blade, and the publishing server does logging for all other processing servers. So you might want to consider using multiple writing threads for slower disks. The minimum value is 1. The default value is the number of processing servers configured in your system. `TransactionServer:How many writing threads do you want to use for transaction logging?` The latency write time in milliseconds that triggers the writing of logging statistics to the mtx_debug.log is 50. A value of 0 disables the writing of logging statistics. `TransactionServer:What is the latency write time in milliseconds that will trigger the writing of logging statistics to the mtx_debug.log?` The character that separates two timestamps in a transaction log filename when an original time is included. The default value is a colon character, ":". Valid separator values are a hyphen "-", or a colon ":". `TransactionServer:What separator do you want to use to separate the timestamps in a log filename?`
Transaction Server Hash Index	Hash index merging and rebalancing can be configured manually by changing the answer to the following questions to `n` and answering the following questions. `Do you want to use the default hash index block size configuration (y/n)?` `Do you want to use the default hash index scheduling configuration (y/n)?` Note: Hash index configuration must not be changed unless a MATRIXX configuration expert has instructed you to do so. Wrong values can affect the operation of the system. `How many mappings you want to configure for each hash index block?` `Config:TransactionServer:When do you want to start the "hash index merge and rebalance" job?` `Config:TransactionServer:How often do you want run the "hash index merge and rebalance" job?` `Config:TransactionServer:What is the free queue size threshold for on-demand merging?` `Config:TransactionServer:What is the index block chain length threshold for on-demand rebalancing?` `Config:TransactionServer:What is the average block chain length per bucket we can grow before we need to add a new bucket chain?`	y
Input Queue Size	`Do you want to use the default input queue sizes (y/n)?` `Do you want to use the default input queue sizes for the transaction_server (y/n)?`	y y
Default Number of Threads	`Do you want to use the default number of threads (y/n)?` `Do you want to use the default number of threads for the transaction_server (y/n)?`	y y
Transaction Server's restart mode	The restart mode determines how each Transaction Server populates its databases and joins the transaction protocol when a cluster starts. `init` mode is used for unit testing. In this mode, the server topology is determined from the static `mtx_config.xml` file because the Cluster Manager is not enabled. Each Transaction Server starts with an empty database or restore from a checkpoint (if checkpointing is enabled) to populate its databases. After that, it is ready for message processing. When processing the transaction, it assumes the servers in the configuration participates on the transaction protocol. `warm` mode is used in production systems, where the HA Cluster Manager is enabled. When a Transaction Server starts up with either an empty database or restored from checkpoint, it waits for the system control message to tell it the current topology. If Transaction Server is the first processing server in the cluster, it loads the pricing data. If it is not the first processing server in the cluster, it synchronizes its database and is ready for message processing. The server topology is dynamically determined by the Cluster Manager. In production systems, this value must be set to `warm`. create_config.info question: `What is the Transaction Server's restart mode?`	init
Fast Restart Database Copy Network	To specify the network interface to use for fast database restarts, answer `txn`, `mgmt`, or `data` in response to the create_config.info question: `Which network interface for fast restart database copies?`	txn
GTC Sorter Size for Processing Server	Specify the GTC Sorter size (a count of the number of records to process) on the processing server for sorted transaction logging. create_config.info question: `TransactionServer:What is the gtc sorter size for sorted transaction logging?`	25000
GTC Sorter Size for Publishing Server	Specify the GTC Sorter size (a count of the number of records to process) on the publishing server for sorted transaction logging. create_config.info question: `TransactionServer:What is the gtc sorter size for sorted transaction logging on publishing server?`	25000

In addition to these create_config.info parameters, integrators can change the default configuration for how the Transaction Server proactively tries to resolve pending transactions during runtime. Define a selective update to change the following parameter value:

<resolve_pending_transaction_interval_in_micros> 
<resolve_pending_transaction_maximum_retries>

By default, the Transaction Server on each server looks every 60 seconds (60000000 microseconds) for transactions that has been idle once and tries to resolve any that are pending. If the same transaction cannot be resolved after the maximum number of retries (default is 3), it logs a critical message and stops trying to resolve the transaction. This might require a manual restart of the server that has not approved the transaction commit.

The parameter gtc_sorted_txn_logging_enabled is for use in systems and logging. It has a Boolean value of 1 or 0. gtc_sorted_txn_logging_enabled Parameter describes the impact of gtc_sorted_txn_logging_enabled in MEF files.

Table 2. gtc_sorted_txn_logging_enabled Parameter
General	MEF
Processing servers continue to create log files but do not support `gtc_sorted_txn_logging_enabled`.	The parameter is enabled by default, and cannot be disabled.

You can also use the batch_level_compression_enabled parameter in a sed command to specify whether to enable or disable batch-level compression for transactions. Batch-level compression is enabled by default.

Note: If batch-level compression is not enabled, transactions are compressed individually, which can increase I/O because the compression ratio is not good for smaller messages.