- This topic has 22 replies, 6 voices, and was last updated 9 years, 9 months ago by Zeb.
-
AuthorPosts
-
December 9, 2014 at 5:43 pm #779uRADMonitorKeymaster
I love this idea. Clean and efficient!
December 9, 2014 at 6:44 pm #800vinzMemberHello Hexide,
that’s a good point, didn’t think about that. We should do that.
It will help, if main-server is down (hardware, os, ..).
1) but it will not help, if DNS-entry is taken.
2) and we’d have to check, if the devices DNS-client can handle this at the moment. Maybe I could check that offline.Also we then/still have the problem of syncing several (in this case) MySQL-master-databases.
I only know about syncing from one master’DB to several client’DBs. There data is written to one DB only – and users read (requests…) from the client’DBs where a minimum mismatch doesn’t matter (not the newest data available).In our new scenario we’d need to synchronic several master’DBs, which are all written
Is this possible with MySQL? What about the conflicting primary-keys?
Vinz
P.S: The correct words to search are “replication” and “master-master-replication”.
December 9, 2014 at 6:51 pm #805HexideParticipantFor synchronization extra layer might be required, something like http://www.rabbitmq.com/. Not entirely sure if RabbitMQ is good for this task, but there are alternatives.
Potential problems are that databases will have same data, but not in same order between masters.
December 9, 2014 at 6:53 pm #806HexideParticipantStill, single MySQL master ( with stand-alone slave as backup ) would probably be best. If in any case master dies, slave could take over ( not automatically ).
December 9, 2014 at 7:41 pm #816vinzMemberSo slaves will take over
1st via the DNS-entry you described
2nd via a new backup url, stored in the devicejust to store their data. This data have then to be brought together manually.
Hm..But please consider/keep in mind: Devices will not leave the secondary-server anymore, once the choosed it. (as long as it’s online, and normally it will be).
PS: I’m reading:
http://www.percona.com/doc/percona-toolkit/2.1/pt-table-sync.htmlDecember 9, 2014 at 8:33 pm #817ZebParticipantI have run MySQL in master-master mode with two nodes. It makes no difference which node an operation is performed on, even simultaneous inserts are fine providing the primary key is an AUTO_INCREMENT column. The key thing is to make sure that the following paramters are configured correctly (for example):
Server 1
server-id = 1
auto_increment_increment = 10
auto_increment_offset = 1Server 2
server-id = 2
auto_increment_increment = 10
auto_increment_offset = 2Simultaneous inserts on both servers would have insert IDs of 11 and 12. An insert on node 1 then 2 then 1 then 2 would have the insert IDs: 11, 22, 31, 42.
December 11, 2014 at 8:01 pm #853vinzMemberuh, I wrote an answer 2 days ago, it’s gone.
This sounds logic, it’s very nice! 🙂
I’d like to test this in a local environment.Data stored this way can easily brought together manually.
But did you do it automatically? How did you do this setup (replication both sides).Vinz
December 14, 2014 at 4:27 pm #934ZebParticipantApologies for the delayed reply. As long as the MySQL/MariaDB servers are configured correctly then the replication is fully automatic and should one of them be offline for any period, it will synchronise with the other server once it is back. This allows us to take one of the servers down for upgrades, etc. without any effect on the service.
I’m sure I have some notes on the configuration somewhere…
I haven’t used MariaDB yet but will be in the next couple of weeks for a large database (using Piwik).
We’re moving from MySQL 5.1 to MariaDB 5.5 as the later versions (5.4+, I seem to recall) have multi-threaded support. Otherwise only a single CPU core can be used which seriously affects performance.
-
AuthorPosts
- You must be logged in to reply to this topic.