Is there a way to upgrade from Aurora 1 (MySQL 5.6) to Aurora 2 (MySQL 5.7) without downtime on an active database? This seems like a simple task given we should be able to simply do major version upgrades from either the CLI or the Console, but that is not the case.
We tried:
Creating a snapshot of the database
Creating a new cluster using Aurora 2 (MySQL 5.7) from the snapshot
Configure replication to the new cluster from the primary cluster
However, because you can't run commands that require SUPER user privileges in Aurora you're not able to stop transactions long enough to get a good binlog pointer from the master, which results in a ton of SQL errors that are impossible to skip on an active database.
Also, because Aurora is not doing binlog replication to its Read replicas I can't necessarily stop replication to that read replica and get the pointer.
I have seen this semi-related question, but it certainly requires downtime: How to upgrade AWS RDS Aurora MySQL 5.6 to 5.7
UPDATE: AWS just announced in-place upgrade option available for 5.6 > 5.7:
https://aws.amazon.com/about-aws/whats-new/2021/01/amazon-aurora-supports-in-place-upgrades-mysql-5-6-to-5-7/
Simple as Modify and choose version with 2.x. :)
I tested this Aurora MySQL 5.6 > 5.7 on a 25Gb db, many minor versions behind and it took 10 min, with 8 min of downtime. Not zero downtime, but a very easy option, and it can be scheduled in AWS to happen automatically during off-peak times (maintenance window).
Additionally consider RDS Proxy to reduce downtime. During small windows of db unavailable time (eg. reboot for minor updates), the proxy will hold connections open, instead of completely unavailable, simply appearing as a brief delay/latency, only.
Need was to upgrade the AWS RDS Aurora MySQL from 5.6 to 5.7 without causing any downtime to our production. Being a SaaS solution, we could not afford any downtime.
Background
We have distributed architecture based on micro services running in AWS Fargate and AWS Lambda. For data persistency AWS RDS Aurora MySQL is used. While there are other services being used, those are not of interest in this use case.
Approach
After a good deliberation on in place upgrade by declaring a downtime and maintenance window, we realized that having zero downtime upgrade is the need. As without which we would have created a processing backlog for us.
High level approach was:
Create an AWS RDS Cluster with the required version and copy the data from the existing RDS Cluster to this new Cluster
Setup AWS DMS(Data Migration Service) between these two clusters
Once the replication is done and is ongoing then switch the application to point to the new DB. In our case, the micro-services running in AWS Fargate has to upgraded with the new end point and it took care of draining the old and using the new.
For Complete post please check out
https://bharatnainani1997.medium.com/aws-rds-major-version-upgrade-with-zero-downtime-5-6-to-5-7-b0aff1ea1f4
When you create a new Aurora cluster from a snapshot, you get a binlog pointer in the error log from the point at which the snapshot was taken. You can use that to set up replication from the old cluster to the new cluster.
I've followed a similar process to what you've described in your question (multiple times in fact) and was able to keep the actual downtime in the low seconds range.
Related
We are currently setting up AWS hosting for our Web Application.
This Laravel Web Application will have a Schema per company that registers, meaning it will have a large sized mySql server.
I have gone through the motions of setting up a VPC with EC2 instances and and RDS for this mySql server.
However we are currently looking at using Laravel Forge as a tool to host.
What Forge does differently is that it includes the mySql Server on the EC2 instance not on an RDS.
The question I have come to ask here is, what are the implications if any of having the mySql server on the EC2 instance rather then an RDS.
Would there be performance issues?
Is it better practice to have an RDS?
Or is Forges out the box way of packaging this all together on an EC2 server fine?
By running this on an EC2 instance you will taking more of the responsibility of managing the database, not just installation but also patching, backups, recovery. Harder to maintain functionality such as replication and HA will also be on you to implement and monitor.
By running on RDS AWS is going to take the heavy lifting of this and implement a best practice version of MySQL which offers the flexibility of allowing you to run a MySQL stack in the cloud without having to really think about the implementation details under the hood other than deciding do you want it to be HA and how many replicas do you want.
In saying this by using RDS you're also giving up the ability to run it however you want, you are limited to the versions of the database that RDS supports (although this is now quite soon after release). In addition not all plugins or extensions will be active so check this functionality before deciding.
I wanted to know if we can migrate an oracle database from on premise to AWS, using aws/open source tools/services only with zero downtime. The preference is just AWS services. since this is a 1 time requirement we are not interested in purchasing third party tool licenses. The important requirement for this POC is that there shouldn't be any downtime.
Kindly let me know if you can provide me any inputs for the same.
Thanks
To reduce database downtime, use standby technology.
Install Oracle software only(same version on premise server) on the new server AWS EC2.
Perform a hot backup on the premise server.
Restore the hot backup to the new server AWS EC2.
Configure the standby between the premise Oracle servers
and new AWS EC2.
Make switchover role primary to standby AWS EC2.
I was wondering whether MySQL commands like NOLOCK or creation of indexes is actually supported on Aurora AWS? Also, can I do performance issue investigation or is Aurora AWS a "black-box" to me?
The Aurora it is completely different database than MySQL, but when it comes to the compability with MySQL or PostgreSQL Amazon team did a lot so that there would not be a lot of differences. "The Amazon Aurora MySQL is designed to be wire-compatible with MySQL 5.6 and 5.7 using the InnoDB storage engine. Certain MySQL features like the MyISAM storage engine are not available with Amazon Aurora." Amazon Aurora MySQL 2.01 does not currently also support the following MySQL 5.7 features:
Global transaction identifiers (GTIDs)
Group replication plugin
Increased page size
InnoDB buffer pool loading at startup
InnoDB full-text parser plugin
Multisource replication
Online buffer pool resizing
Password validation plugin
Query rewrite plugins
Replication filtering
The CREATE TABLESPACE SQL statement
X Protocol
(source:https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.2022.html)
But it changes from release to release.
Answering to you question about a performance monitoring. You can monitor Aurora database from AWS Console or by using queries directly on Aurora database, the same as in case of MySQL. Staring from version 2.03 there is also available the performance schema.
UNLOCK command - I am not sure whether it also exists in native MySQL, but there is possiblity to set transaction isolation level.
Indexes - yes, you can also create indexes on Aurora.
I hope the information will be useful for you.
I want to migrate an EC2 instance of MySQL 5.5 to, at least, MySQL 5.6 (ideally to MariaDB 10,x) on RDS. Naturally, I'm going to use replication to do that. Part of the procedure requires a master-master setup between EC2-Mysql and RDS-Mysql and I don't think that's doable (been trying for awhile).
The reason for the master-master setup is this: Once the application is pointing to the RDS endpoint, I'd like any changes made to the RDS database to be replicated to the EC2 database in case we decide to rollback to using the EC2 instance. The MM setup won't be for long; probably overnight at most. And I can't think of a reason to roll back to using the EC2 instance, but I'm overly paranoid when it comes to production data.
Is it possible to have a master-master setup with EC2 and RDS? Some sites say "no", others, "yes". I've been trying but keep running into problems (internal timestamp formats, lack of STATEMENT based replication on RDS, etc.).
If I can't do an MM replication, is there another way for me to be able to roll back JIC?
Oh, and I can't use AWS' Database Migration Service since I have a couple thousand databases to migrate (don't ask).
We're planning to move our Tomcat/MySQL app onto the Amazon cloud employing 2 EC2 instances (inst_1 & inst_2) running in different availability zones whereby inst_1 will contain the master RDS db and inst_2 the slave RDS db.
If we employ elastic load balancing to balance traffic between the two instances, will traffic directed to inst_2 that includes insert/update/delete db transactions first update the master RDS db in inst_1 followed by a synchronous update of the slave in inst_2; thereby ensuring that the two RDS instances are always synchronized?
Amazon's published info (whitepapers) suggests such, but doesn't explicitly state it. If not, how does one ensure that the two RDS instances remain synchronized?
Additional note: We're planning to employ Amazon's Elastic Beanstalk. Thanks!
You have to take a few things into consideration
AWS RDS instances are simple managed EC2 instances which run a MySQL server.
If you add a slave ( I think Amazon calls them read-replica) this is a read-only slave
Amazon doesn't manage the distribution of writing queries to the master server automatically.
Replication will ensure that your read slave always is up-to-date automatically ( with minimal delay which is increasing with write-load on the master )
This behavior is MySQL-specific
This means that you have to delegate manipulating queries to the master exclusively.
This can either be done by your application or by a MySQL proxy running on a extra machine.
The proxy then is the only interface your application servers will talk to. It is able to manage balancing between your RDS instances and the direction of any manipulation query to the master instance.
When RDS is used in multi-az mode you have no access to the secondary instance. There is only ever one instance that is visible to you, so most if your question doesn't apply. In case of failover the DNS address you are given will start resolving to a different ip. Amazon doesn't disclose how the two instances are kept in sync.
If instead of using a multi-az instance you use a single-az instance + a replica then it is up to you to direct queries appropriately - any attempt to alter data on the replica will fail. Since this is just standard MySQL replication, the replica can lag behind the master (in particular with current versions of MySQL the replica only runs a single thread)