MySQL replication best practices - mysql

I'm setting up MySQL replication via binlog. It's a master / slave setup.
I have a few questions on how to do this the best way.
Should information_schema be replicated, if yes/no, why?
Should mysql db be replicated, if yes/no, why?
If it all should be replicated, no binlog-do-db needs to be set?
Cheers.

No, Information Schema should NEVER be replicated. This is meta data about your tables, dbs, routines, triggers, etc. Let the server populate it's own information_schema.
mysql db is fine to replicate, especially in the instance where you will be setting up a number of users. If your master fails, you will need the same user information available on your slave server in order to fail over to it. If that should occur, you need to have the same privileges available.
List only the database you want replicated with binlog-do-db. If you don't list any, everything will be replicated by default.

No. need to replicate information schema read this for detail https://dev.mysql.com/doc/refman/5.0/en/information-schema.html
Yes you can because mysql database contains all user credentials so in order to have a backup of users you can replicate it.
Yes use binlog-do-db to replicate selected databases otherwise everything will be replicated if nothing mentioned.

Related

Setting up MySQL (Master-Slave) replication with all ready configured databases/tables

I am trying to configure MySQL databases using the Master-Slave replication. Before I realized that I had to set up my environment using this replication, I already have 2 separate servers running their own MySQL DB. Each of these servers are configured the exact same. The MySQL DB are configured with hundreds of tables.
Is there a way that i can set up (Master-Slave) Replication using the configured DB's? Or will i have to start from scratch and configure the replication first and then load in all the DB tables?
You can delete all data from one of the servers. Remaining one with the data will be your Master. Then use mysqldump to backup all the data and insert it to the slave.
Take a look for the detailed instructions on the page below:
https://livecaller.io/blog/how-to-set-up-mysql-master-slave-replication/
If the data is exactly same in both the MySQL database then you can start master slave replication, but you need to be sure that the data is same. MySQL will not check that, and if there is some discrepancy in the primary key then it will throw error immediately after next DML statement.
To be on a safer side, drop the database from one server, and restore it using the MySQL dump of another server. This will give the surety that database is same on both the server.
Take the reference from the below link to establish replication between two MySQL servers.
https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-in-mysql

access master table from replica

I have two mariadb servers one is configured as master and the other as a replica of this master. I have created a database named params on master and it has a table with a couple of items in it.
How can I see this table and access or modify it using the mysql shell on the replica?
Is this even possible or I have miss understood the replication altogether?
Check that replication works
If you aren't seeing the database on the slave replica, it would be good to check that the output of SHOW SLAVE STATUS doesn't return any errors. A good resource for getting started with replication is the MariaDB KB article on the subject.
When you have confirmed that replication works, you can connect to the slave replica and you should see the database there.
How replication works in MariaDB
Replication in MariaDB will propagate all changes that happen on the master server to any slave servers that are replicating from it. This allows you to read the same data from multiple places without burdening the master server. It does not allow you to seamlessly share data across multiple servers (a Galera cluster offers some of this).
The downside of master-slave replication is that when you want to make a change, you have to make it on the master in order to keep the data consistent across all servers. The benefit of it is the higher availability of your data and increased throughput of read queries. The Replication Overview article has a more detailed description of what replication is and lists some use cases for it.

Can mysql replication be configured to prevent drop database being replicated?

Can mysql replication be configured to prevent certain commands being replicated to the slaves.
Imagine a completely invented scenario where someone types
drop database foo;
into the wrong ssh window
(I know, it can never happen)
Currently mysql will replicate that command to the slaves.
Can you block that and so redirect the application server to use on of the slaves and keep systems running.
I fully understand that this question is only one dimension of a DR strategy.
We run mysql 5.5
replicate just one database and do not grant drop database to the user on slave server
replicate-do-db=db01
or replicate table per table:
replicate-do-table=db_name.tbl_name
sorry the poor english

Replicating Different Databases to Different Slaves

I need to replicate some databases as shown below.
-DB1---replicate to---> SLAVE_A
/
MASTER <--DB2---replicate to---> SLAVE_B
\
-DB3---replicate to---> SLAVE_C
The process described here would work well if I controlled both the master and all slave servers, but unfortunately I only control the master in this case. The slaves will potentially be in different countries, run by other admins.
My concern is that the configuration on SLAVE_A could easily be changed to replicate not only the intended DB1, but DB2 and DB3 as well, which is not good.
The only hope I have of limiting which slave replicates which database is if I can somehow control it from the master, which, from what I've been able to figure out, can't be done. A user has replication privileges either to all databases or none, which is unfortunate.
Am I missing something here, or is this just a limitation in MySQL?
Any thoughts on how this could be accomplished?
Thanks.
On the slave server there is possibility to filter transactions to apply by replicate-do-db or replicate-ignore-db parameters, included in my.cnf file or in command line as option.
The same can be done on master with binlog-do-db or binlog-ignore-db but then - it limits replication do some certain databases on the master. So for you better solution is to filter transactions on the slave.
Create a different MySQL user for each replication slave, and give that user access only to the database you want it to have replication access to.
You can read more in the MySQL Documentation: 16.1.1.3. Creating a User for Replication
CREATE USER 'slave_a'#'some_slave_server' IDENTIFIED BY 'slavepass';
GRANT REPLICATION SLAVE ON `DB1`.* TO 'slave_a'#'some_slave_server';
FLUSH PRIVILEGES;
And then repeat for Slaves B and C on DB 2 and 3 respectively.

MySQL database replication

This is the scenario:
I have a MySQL server with a database, let's call it consolidateddb. This database a consolidation of several tables from various databases
I have another MySQL server, with the original databases, these databases are production databases and are updates daily.
The company wants to copy each update/insert/delete on each table in the production databases to the corresponding tables in consolidateddb.
Would replication accomplish that? I know that replication is done on a databas to database, but not on tables that belong to different databases to one target database.
I hope my explanation was clear. Thanks.
Edit: Would a recursive copy of all tables inn each database to the single slave work? Or is it an ugly solution?
To clear up some things, let's name things accordingly to current mysql practice. A database is a database server. A schema is a database instance. A database server can have multiple schemas. Tables live within a schema.
Replication will help you if you want to duplicate schemas or tables as they are defined on the master/production server. The replication works by shipping a binary log of all the sql statements that are run on the master to the slave which dutifully runs them as if they run sequentially on itself.
You can choose to replicate all data, or you can choose some of the schemas or even just some of the tables.
You can not choose tables from different schemas and have them replicated into one schema, a table belongs to a specific schema.
By the way, important notice. A replication server can not be a slave to multiple masters. You could mimic this using federated tables, but that would never copy the data to the consolidation server, just show them as if the data from different servers were on one server.
The bonus of replication is that your consolidation server will more or less have updated data all the time.
You could take the binary logs from each of the masters, parse them with mysqlbinlog and then run that into the consolidated machine.
Something very approximately like:
mysqlbinlog [binary log files] | mysql -h consolidated
you'd need some kind of simple application (I suspect it could be done in bash if you needed) to wrap the logic.
Check out Replicating Different Databases to Different Slaves, see if it helps you in any way.
MySQL statement-based replication (basic replication) works by running the exact same statements that were run on the master on the slave. This includes information about what database the table was in.
I don't think MySQL provides any built-in way to move replication statements between databases (i.e. "insert into db1.table1 ..." -> "insert into db2.table1"). You may be able to trick it by manually altering the replication logs on the fly, but it wouldn't be out-of-the-bod MySQL replication.
You might be able to pull it off with MySQL Proxy
You may want to check out the maatkit toolkit. It's a free download and has a host of tools that specialize in optimizing things like archiving tables. I've used it on past projects to duplicate certain data to another DB, etc. You can do it based on time or any other number of factors.
To the best of my knowledge you can set up replication (MySQL 4+) and in the my.cnf file have the slave either only process certain tables or have the master log only certain tables, either way will solve your problem.
Here is a guide to some techniques:
http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html
I have very few problems with replication set-up, all my problems came trying to sync DBs, especially after a reboot etc.