I have a situation here that will have 2 MySQL servers linked over a WAN. Each location (lets call them Location X and Location Y) will need access to three databases (Lets call them A, B and C.
Location X needs to use Database A as their main database, and database B as a 'lookup' read only database.
Location Y needs to use Database B as their main database, and database A as a 'lookup' read only database.
BOTH locations need read/write access to a replicated database C. (This database contains no auto incrementing columns etc. - fairly simple logging tables).
In essence, I need a combination of master-slave AND master-master replication happening:
X Y
--------
A --> A
B <-- B
C <--> C
Is this feasible to set up on MySQL?
MySQLD-Multi Is a package that can help you accomplish this. Individual MySQL databases can only have one master. If you setup A series mastered in one direction, and your B series mastered in the opposite direction, they would need to run on their own IP or port numbers. Likewise for C.
Multimaster setup becomes arduous if you get data transmission errors, lose table space, or get struck by thundering herds and drop connections. You will likely end up in the un-enviable position of using a log-based recovery tool to re-sync them. Please consider that your application will want to very cautiously use its "write" privileged connection and rely heavily on read connections.
Splitting up MySQL instances in this manner allows for latency between applications to isolated better. In a multi-master situation, you commonly have to watch the latency and begin failing things out of your pool if they differ even by 1 second of latency. If you truly need MM for your C-series, serioiusly consider chaining read-only slaves on each end for your C-series to minimize latency on the write-masters.
I'd suggest using Percona XtraDB Cluster.
PXC is a MySQL derivative server (so everything about using it will seem familiar except for the replication part). It supports synchronous bidirectional replication over a WAN, so both site X and Y can write to its main database, which will then be replicated to the other site. PXC even supports writes to a database on both sites, which satisfies your requirement for database C.
Percona XtraDB Cluster is free and open source software, like all Percona products.
Disclaimer: I worked for Percona 2010-2014.
Related
I have a couple of servers and I want to prepare a Master - Slave Mysql replication for one database. The both servers have many databases and I don't want to altere the secuence of ID generation. For example, after I have prepared the configuration I don't want to have in the tables just even numbers for the all the IDs in one of servers.
The replicated database (slave server) will be not accesed for write.
Is posible to configure that scenario?
Many thanks in advance.
Update: The server_id has nothing to do with id generation. It just needs to be a unique integer greater than 0 on each server in your replica-set.
Below is my original answer, which was my guess about what you were asking about, because it's the only feature I could think of that has to do with both replication and auto-increment id generation.
You don't need to change id generation for simple replication.
The scenario where you might use auto_increment_increment=2 is the master-master replication, where two servers replicate from each other, and you want to minimize the risk of split-brain if an insert occurs on both servers. But this is not the scenario you describe.
If you have one master, and it's the only server you write changes on directly, and the replica(s) that replicate from that master are all read-only, then you don't need to change the auto_increment_increment.
Imaging that I have a number of servers which all run mysql or mongodb or redis database,
the servers are in different places. I want to keep the server's data all the same.
for example:
server A,B,C,D,E
1> insert items to A, auto update B,C,D,E
2> insert items to B, auto update A,C,D,E
3> delete ...
Your question is rather generic but the answer in all cases is a similar starting point for syncing the same data to multiple servers:
MySQL - use replication
MongoDB - use replication
redis - use replication
Depending on the database, you may have limitations such as whether replication is single master (all of the above generally are, out of the box) or whether you truly need multi-master updates (eg. MySQL Cluster, CouchDB, or other database with MVCC).
There are pros and cons of different approaches, and it really depends on your use case and where the servers are in relation to each other (same data centre, geographically diverse, etc). Generally you would want to scale up to the appropriate scenario rather than trying to start out with something overly complex to set up and support.
What is the best strategy to make a clustered MySQL deployment in which some tables of the DB are placed on one node and some other tables are placed on another node while acting as a single coherent DB from the application's perspective?
Let's say if I have 2 data nodes A and B, and a database with 5 tables, I want tables 1, 2, and 3 to be placed on node A and tables 4 and 5 to be placed on node B.
Do we need this deployment to be a clustered deployment, or would a typical MySQL deployment handle this? If yes, how so?
How about having table 4 replicated on both A and B?
MySQL will allow for transparent access to tables stored on other instances using the federated engine (this has been available for a long time).
MySQL does provide a feature called partitioning - which is applied to tables to distribute the data across different filesystems - but this is something very different.
How about having table 4 replicated on both A and B?
You can set up mysql replication to only copy specific tables (see replicate-wild-do-table) however mixing federation and replication is going to get very confusing very quickly - get it wrong and you will trash your data. Use one or the other. Not both.
I'm trying to find a solution for creating a small mysql cloud. I don't need it for storage, it's more for reliability. Is it possible to have 2 identical mysql servers and if one goes down the other is still working and will sync when it comes back online? The idea is kinda like a RAID-1 setup, but intead of HDDs I want to use two whole servers.
Is there a solution like this out there? I was looking at onapp, but it may not work well with mysql.
Using MySQL replication.
using active-pasive with rdbd + heartbeat
In any case you would need use DNS to automatically update the IP or VIP
What you want is MySQL Master-Master replication, which will work as you request.
We did this once with 6 mysql servers doing replication in a circular chain. The replication chain was:
A -> B -> C -> D -> E -> F -> A
When a failover was detected the master was moved from A to B (an so forth) - DNS was updated for the master - but reads where taken from random member of the chain.
You want MySQL replication. There are a number of ways to set it up; have a look at that doc.
Previously, I have experience in doing the following database replication.
(1) I have 2 tables within 1 database in Machine A
(2) I update 2 tables in Machine A
(3) Machine A will replicate 2 tables to Machine B. Machine B will also contain 2 tables within 1 database.
Now, I would like to accomplish the following :
(1) I have Table A, within 1 database in Machine A.
(2) I have Table B, within 1 database in Machine B.
(3) I would like to replicate Table A and Table B to Machine C.
(4) Machine C will have Table A and Table B, within ONE database.
Is it possible this to be accomplished, through database replication?
Unfortunately, you can have only Master per mysql server. So for instance you could run two separate instances of mysql on different ports on Machine C that slaved from Machine A and Machine B respectively, but not from both in one server.
Depending on your situation, doing that might be get you close enough that some other replication technique (like periodically using mysqldump to copy one table across on Machine C) would work. It would just depend on your needs for the slaves (how big are the tables (i.e. how quickly can they be copied via a non-slaving method), how out of date is acceptable, do you really need them in one DB or is one server good enough, etc).
After a second thought, there is one type of multi-master replication which is possible and might serve your needs if you just want the data in one DB and don't really need Machine C. In that case, you could actually have one of the servers be the Master for Table A and Slave for Table B, while the other is Master for Table B (and if necessary, Slave for Table A). Decent looking explanation.
Multi-master replication isn't really possible unless your using Cluster, then I don't think you can use the example your talking about unless the two tables are really the same data simply seperate partitions.