MySQL Forums
Forum List  »  NDB clusters

Active-active replication
Posted by: Odis Yuck
Date: November 20, 2015 08:14AM

Hello.
I'm trying to use active-active replication.
Configs are same for both SQL servers:


server-id=1

log-bin-trust-function-creators = 1
log-bin=log-bin.log
binlog-format=ROW
ndb-log-orig=1
ndb-log-transaction-id=1
#ndb-log-update-as-write=0

log-slave-updates=1

ndb-log-apply-status=1

replicate-wild-do-table=devel.%
replicate-wild-do-table=mysql.ndb_apply_status
replicate-wild-do-table=mysql.ndb_replication

(only "server-id" is different for another server).

I have many questions. Please, help me to go into the matter.


Firstly, is this config correct for active-active replication?


Secondly, what exactly I must have in mysql.ndb_replication table?
According to documentation,
> Because the conflict detection algorithms employed by NDB$EPOCH() and NDB$EPOCH_TRANS() are asymmetric, you must use different values for the primary slave's and secondary slave's server_id entries.

Now I have such row:

*************************** 1. row ***************************
db: devel
table_name: %
server_id: 1
binlog_type: 0
conflict_fn: NDB$EPOCH2_TRANS()
1 rows in set (0,01 sec)


I must add another row with server_id=2?



Thirdly, now I get errors about LOST EVENT. Is it normal for active-active replication? I suppose that both servers know current position of binlog at remote server and at localhost, so both can continue to download binlog from remote server from right position. We have conflict resolution, so servers can figure out what rows are correct.
If servers know position for downloading binlog and can deal with inconsistency, there must not be LOST EVENTS errors. Am I wrong?


Thanks.

Options: ReplyQuote


Subject
Views
Written By
Posted
Active-active replication
2130
November 20, 2015 08:14AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.