maria-developers team mailing list archive
Mailing list archive
Re: Fwd: possible bug in MySQL 5.6.7-rc slave replication crash safety?
Thinking more about this, I cannot quite make up my mind of the best approach.
I would like to get some input.
On the one hand, when binlog is enabled on a slave, it really is the best
solution for storing replication state and crash safety.
On the other hand, running a slave with innodb_flush_log_at_trx_commit=0 and
no binlog will perform much faster and makes a lot of sense for some setups
(after all if we crash we can just replicate again any transactions lost).
It seems to get the best of both worlds, we need a dual approach.
When binlog is enabled, we use it to store and crash-recover slave state.
When binlog is disabled, every transaction inserts a row in some table
containing the global transaction ID. After a crash we then obtain the last
applied transaction with SELECT MAX(...) from that table. And we need to
periodically delete old rows.
Both methods work with any (XA-capable) storage engine. However, the table
approach will have a large overhead when the engine used for the table is
different from the engine used in transactions.
Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
> Zardosht Kasheff <zardosht@xxxxxxxxx> writes:
>> Thank you for the reply. I want to make sure I understand this
>> correctly. Is the planned design for crash safe replication to be that
>> the slave must have the binary log enabled, so that slaves may use the
>> GTID and XA to ensure that the slave and master are in sync? If the
>> binary log is not enabled, then the slaves are not crash safe. Is my
>> understanding correct?
> I know of three different features that touch on "crash safe slave":
> 1. MDEV-26. If/when this is implemented, the plan is that the state is made
> crash-safe using the binary log, as you said.
> 2. The MySQL feature, where we store in a transactional table the info that is
> now in relay-log.info.
> 3. The XtraDB hack, where InnoDB overwrites the relay-log.info at startup from
> internal data salvaged from the InnoDB redo log.