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.
Related
How can I connect two separate databases so that when some update is performed on a piece of data on one database , the change happens also on the data in the other one .?
this is really simple you must have 2 databases, 1 must be marked as a master, while other db must be slave. you 'll always insert data in master database, which will replicate this to slave database.
you must be careful because every change on master will be replicate to slave.
to understand the entire process here I am referring you to read this post
I have 2 Databases
Database 1,
Database 2
Now Each Database has Table say Table 1(IN DATABASE 1) and Table 2(IN DATABASE 2).
Table 1 is Basically a Copy of Table 2(Just for Backup).
How can i Sync Table 2 if Table 1 is Updated?
I am using MYSQL,Storage Engine:InnoDBand in back-end programming i am using php.
Further i can check for update after every 15 minutes using php script but it takes too much time because each table has51000 rows.
So, How can i achieve something like if Administrator/Superuser updates table 1, that update should me immediately updated in Table 2.
Also, is there a way where Bi-Directional Update can work i.e Both can be Masters?
Instead Table 1 as the only master, Both Table 1 and Table 2 can be Master's? if any update is done at Any of the tables other one should update accordingly?
If not wrong, what you are looking for is Replication which does this exact thing for you. If you configure a Transnational Replication then every DML operation will get cascaded automatically to the mirrored DB. So, no need for you to do continuously polling from your application.
Quoted from MySQL Replication document
Replication enables data from one MySQL database server (the master)
to be replicated to one or more MySQL database servers (the slaves).
Replication is asynchronous - slaves need not be connected permanently
to receive updates from the master. This means that updates can occur
over long-distance connections and even over temporary or intermittent
connections such as a dial-up service. Depending on the configuration,
you can replicate all databases, selected databases, or even selected
tables within a database.
Per your comment, Yes Bi-Directional Replication can also be configured.
See Configuring Bi-Directional Replication
As Rahul stated, what you are looking for is replication.
The standard replication of mysql is master -> slave which means that one of the databases is "master", the rest slaves. All changes must be written to the master db and will then be copied to the slaves. More info can be found in the mysql documentation on replication.
There is aslo an excellent guide on the digitaloceans community forums on master <-> master replication setup.
If the requirements for "Administrator/Superuser" weren't in your question, you could use the mysql's Replication functions on the databases.
If you want the data to be synced immediately to the Table2 upon inserting in Table1, you could use a trigger on the table. In that trigger you can check which user (if you have a column in that table specifying which user inserted the data) submitted data. If the user is an admin, configure the trigger to duplicate the data, if the user is a normal user, don't do anything.
Next for normal users entering data, you could keep an counter on each row, increasing by 1 if it's a new 'normal' user's data. Again in the same trigger, you could also check for what number the counter already is. Let's say if you reach 10, then duplicate all the rows to the other table and reset the counter + remove the old counter values from the just-duplicated-rows.
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.
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.
Lets say I have a datbase of Cars. I have Makes and Models (FK to Makes). I plan on having users track their cars. each Car has a FK to Model. Now, I have a lot of users, and I want to split up my database to distribute load. The Makes and Models tables don't change so much, but they need to be shared across shards. My thought is to use MySQL replication from a master DB of makes and models to each slave database. My question is: Can I safely write to the slave databases assuming I don't write to those tables on the master?
And while on the subject, is there anyway to guarantee one slave database has the latest data? For example, someone just added the 'Taurus' make, and then wants to add their car. Can I ensure that the slave database they are using has the latest master data?
Yes, in general you can safely write to a table on the slaves that is not being written on the master. If you do things like insert auto_increment rows on the slaves and on the master, independently, you will of course have problems. You should configure that table to be excluded from replication entirely, really.
For checking whether you have the latest data, SHOW SLAVE STATUS includes a field Seconds_Behind_Master that tells you whether the slave is up to date. Obviously you want it to be zero. To be certain that inserted and replicated data is present, of course, you need to wait a second and then see that Seconds_Behind_Master is zero.
This was a good solution I gleaned while searching
I included the main point as avilable here:
http://erlycoder.com/43/mysql-master-slave-and-master-master-replication-step-by-step-configuration-instructions-
MySQL master-master replication and autoincrement indexes
If you are using master-slave replication, than most likely you will design your application the way to write to master and read from slave or several slaves. But when you are using master-master replication you are going to read and write to any of master servers. So, in this case the problem with autoincremental indexes will raise. When both servers will have to add a record (different one each server simultaneously) to the same table. Each one will assign them the same index and will try to replicate to the salve, this will create a collision. Simple trick will allow to avoid such collisions on MySQL server.
On the Master 1/Slave 2 add to /etc/my.cnf:
auto_increment_increment= 2
auto_increment_offset = 1
On the Master 2/Slave 1 add to /etc/my.cnf:
auto_increment_increment= 2
auto_increment_offset = 2