Glen Boyer wrote:
Let me ask you this, If I may ?
You have Server A in San Diego and Server B in New York
You have replication between A ---> B
You have replication between B ---> A What happens when your connection is broke, People Still Update A in San Diego while
People Still Update B in New York
No problem that wasn't there before the break up.
Slaves keep asking even if the get no answer for some time.
You set up the time intervals in which the slave asks the master. Those intervals could AFAIK be days if you want.
What happens when communication is restored?
The client knows until where it read the log, e.g. line 4711.
So it asks the master for everything after line 4711 the next time they chat again.
It is important that the master keeps the logs until every slave has seen them. That is a log rotation problem that gets discussed in the manual, I think.
What happens to auto-increment fields?
Just avoid them. They are evil if you rely on them as keys.
I have the same problem and I think it can only be solved by giving number ranges to the sites like
Site 1 : 1 ... 1000
Site 2 : 1001 ... 2000
.
.
or use 2 field keys to make it somewhat easier: (site_id, sub_id) Still no AUTO_INCREMENT
AUTO_INCREMENT get replicated but I wouldn't trust that the other box didn't insert records in the table already and this info merely didn't reach your side, yet.
and what happens with the data?
Try to be always lucky. ;)
A plain slave that mirrors it's master should be OK. It gets all stuff send that happend while it was disconnected.
2 masters may have created update issues in the meantime. I didn't check this in detail, yet but I suppose there could happen anything if both masters work on the same data.
What if both update the same record. Then exchange the SQL. Probaply their data is different after they repeat the SQL of their peer.
The time between the replication queries is always just relatively short. Probaply locking queries and transactions get replicated but there is a certain timeframe until they reach the other host in this time the other side could change data and those changes could get lost because of replication.
I guess you need a environment where the involved sites generally don't touch the other sites data beyond reading.
Absolutly reliable distributed databases is by no way a trivial problem.
MySQL's approach is good as backup or for load balancing but if you use it beyond that you have to feel pretty lucky or know exacly what your application will do in updates.
I can't claim to know mysql well and I'd love to have someone with better insight who tells me I'm wrong.
;)
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
