C.2.5. Replicator runs out of memory
Last Updated: 2016-05-18
Condition or Error
The replicator runs out of memory, triggers a stack trace
indicator a memory condition, or the replicator fails to
extract the transaction information from the MySQL binary log.
The replicator operates by extracting (or applying) an entire
transaction. This means that when extracting data from the
binary log, and writing that to THL, or extracting from the
THL in preparation for applying to the target, the entire
transaction, or an entire statement within a multi-statement
transaction, must be held in memory.
In the event of a very large transaction having to be
extracted, this can cause a problem with the memory
configuration. The actual configuration of how much memory is
used is determined through a combination of the number of
fragments, the size of the internal buffer used to store those
fragments, and the overall fragment size.
Although you can increase the overall memory allocated to the
replicator, changing the internal sizes used can also improve
the performance and ability to extract data.
First, try reducing the size of the buffer (
) used to hold the transaction fragments. The default for this
value is 10, but reducing this to 5 or less will ease the
Altering the size of each fragment can also help, as it
reduces the memory required to hold the data before it is
written to disk and sent out over the network to slave
replicators. Reducing the fragment size will reduce the memory
footprint. The size is controlled by the
Note that if you change the fragment size, you may need to
reset the service on the extractor so that the binary log is
parsed again. You can reset the service by using the
trepctl reset command.