Is it possible/advisable to create users that only have access to a RDS MySQL Read Replica and not to the main database server? I have a number of power users I'd like to grant access so they can run slow running queries, but don't want to give them access to the main production database itself. Trying to do this directly on the server, I get ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement, so guessing I have to do it in the db parameter group or somewhere like that. Anyway, ideas?
You should not create a user only in the read replica.
It is vital for RDS to have an identical data set for both master and replica instance, so it is not possible to have a user only in the RR and not on the master (or at least inadvisable).
A reason, besides how works the replica in RDS, is that in case of a fail-over a replica can become a master and the roles will be changed
You can add or delete users in a read replica. This is possible by the usual way of CREATE USER . But this is not advisable as the read replica & master should be in sync always so if master goes-down read replica can be promoted as Master.
You can configure an Amazon RDS DB instance read replica to be read/write by setting the read_only parameter to false for the DB parameter group that you create for your DB instance(s).
You cannot modify the parameter settings of a default DB parameter group; you must create your own DB parameter group to change parameter settings from their default value.
https://aws.amazon.com/premiumsupport/knowledge-center/rds-read-replica/
Use caution when doing this, and after you've created the users, put it back to read_only immediately. If you ever create a user on the master with the same username/host pair on the master, replication will likely stop because this creates a conflict.
Related
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
I have 2 MySQL databases running on a server called X and Y, which both have identical content. A series of updates run throughout the day, which changes the content of X. At the end of the day, a process runs that compares the content of X with the content of Y (for various tables) in order to discover new rows, updated row data etc. Once the updates have been processed, mysqldump is used to dump X and then Y is overwritten with the dump. Both X and Y are now the same again, and the whole process repeats.
I'm investigating migration of these databases to Amazon RDS. What's the most efficient way to accomplish the process outlined above?
I understand that I can take a snapshot of a DB and restore it, but I think this is at the instance level only? That would mean I have to run 2 instances, which seems unnecessary. I don't have a problem running both databases on the same instance (I don't want to pay for more than one instance unnecessarily).
Do I just do what I'm doing now i.e. mysqldump X and restore it to Y, or is there some other method/shortcut that RDS provides?
Since the title is concerned AWS instance migration the best way is with my case (can be vary to others case)
Goto -> https://console.aws.amazon.com/rds
Select your DB Instance
Actions -> Take Snapshot
Goto -> https://console.aws.amazon.com/rds
Snapshots from left pane
select your snapshot just created
Action -> Restore Snapshot
After above steps you will be redirected to RDS instance creation page fill out required fields as per requirements and you are done with migration :D
Consider migrating to RDS Aurora for MySQL.
It supports native copy-on-write clones of the entire database (meaning server instance, not schema) without the need to make an actual "copy."
Copy-on-write means the "original" server and the "clone" share the same physical disk (called an Aurora Cluster Volume, which is replicates itself twice across 3 availability zones, using a 4/6 quorum), with both servers sharing the same disk blocks until one of them makes a change... which is when the copy action actually occurs ("on write"). So, you only use as much storage as is required to store your original working data set plus changes that occurred after cloning.
No server is the master in such a setup -- they all operate independently after cloning. I suspect that I'm not doing this innovation justice with my description -- it involves quite a bit of dark magic. See the write-up (with illustrations of copy-on-write):
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Managing.Clone.html
Aurora is compatible with MySQL 5.6. To be more precise, Aurora is MySQL 5.6, with MyISAM removed and InnoDB heavily rewritten to optimize performance and work with the replicated Aurora Cluster Volume storage technology.
A bit late in the day but I have just managed to do this by (1) creating a database back up to S3 and then (2) restoring the backup from S3, i.e.
a. Create database back up in S3
EXEC msdb.dbo.rds_backup_database #source_db_name = '<database-name-goes-here>'
,#s3_arn_to_backup_to = 'arn:aws:s3:::<bucket-name-goes-here>/<backup-filename-goes-here>.bak'
,#overwrite_S3_backup_file = 1;
b. Wait for the task to complete. You can execute the following SQL to check this
exec msdb.dbo.rds_task_status #db_name='<database-name-goes-here>';
c. When the lifecycle is "SUCCCESS" you can then restore from the S3 bucket using the following command
exec msdb.dbo.rds_restore_database #restore_db_name='<new-database-name-goes-here>'
,#s3_arn_to_restore_from='arn:aws:s3:::<bucket-name-goes-here>/<backup-filename-goes-here>.bak';
d. Again you can monitor the status of the restore with the following SQL command
exec msdb.dbo.rds_task_status #db_name='<database-name-goes-here>';
You could setup AWS MySQL RDS instance as a slave of an external master.
After loading a full dump to RDS, Call the stored procedure mysql.rds_set_external_master like this:
mysql> call mysql.rds_set_external_master ('10.10.3.2', 3306, 'replica', 'password', 'mysql-bin-changelog.122', 108433, 0);
Then start the replication by doing:
mysql> call mysql.rds_start_replication;
Once you have data in sync you can promote RDS to master by doing:
mysql> call mysql.rds_stop_replication;
mysql> call mysql.rds_reset_external_master;
By doing this either using your external X or Y servers, the AWS RDS behaves like a replica, the one you could use as your future master if required.
How can I copy the content of a specific table (or the table as is) from my local database to a database instance stored on a cloud, lets say Amazon RDS?
note: it has to be done ones every hour.
EDIT:
Other I/O operations on the local database should no be suspended (e.g. no READ LOCKS).
You can set your local database server to be a master to the Amazon RDS instance which means the Amazon RDS instance becomes a slave in this setup. This is possible to do as mentioned in the AWS documentation here http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.External.Repl.html
You can also configure the slave to update only a specific table in the database after a specified interval of time.
I want to restore mysql rds snapshot with my custom parameter group. does any one know, how can I do this?
Recently fist I have to restore snapshot to new Instance, then edit/change it with security group and parameter group and then restart instance. this is very long and time taking process. on "Restore DB Instance" page, there is no option for "Security Group", "Parameter Group" and "Password".
One more options should be there for restoring snapshot on existing instance or specific database or specific table restore?
No, there is no way to restore a snapshot with custom security groups and custom parameter group. When you restore a snapshot, default security group and parameter groups are applied. Then you to modify the cluster to apply your customer security group and parameter group.
From Restoring From a DB Snapshot:
When you restore a DB instance, only the default DB parameter and security groups are applied. If you need to associate a custom DB parameter or security group to the DB instance, you must apply them explicitly using the RDS console's Modify command, the ModifyDBInstance API, or the rds-modify-db-instance command line tool, once the DB instance is available. The option group associated with the DB snapshot is associated with the restored DB instance once it is created.
So, this is 2 step procedure.
Is there a way to add a new database to the replication without having to restart the master server? I can't seem to find a way and I would like to minimize the downtime to a minimum.
BTW, I tried using this to speed up the restart. Bringing down the value close to 0 on my master takes forever, plus it adds a lot of load on the machine.
I am using MySQL 5.5.20.
You shouldn't need to do anything to enable a new database for replication. All DDL and DML statements should be recorded in the binary log, and be read by the replica and executed by the replica's SQL replication thread.
It's another story if you use replication filtering on the master (--binlog-do-db) or filtering on the replica (--replicate-do-db).
You can use wildcards in any of these replication filtering options, so that you include (or ignore) new databases automatically if the database name matches some naming conventions you design.