Skip to main content

Amazon Database services AWS RDS | AWS Aurora | Aurora MySQL | Aurora PostgreSQL | RDS Oracle | RDS MS SQL Server | RDS MySQL

 AWS RDS vs/ AWS Aurora:

AWS RDS (Relational Database Service) and AWS Aurora are both managed database services offered by Amazon Web Services (AWS). While they are both designed to provide scalable and highly available relational database solutions, there are some key differences between RDS and Aurora:

 Database Compatibility: RDS supports a wide range of relational database engines, including MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB. Aurora, on the other hand, is a MySQL and PostgreSQL-compatible database engine that offers enhanced performance and scalability.

 Performance and Scalability: Aurora is designed to deliver higher performance and scalability compared to traditional RDS database engines. It achieves this by using a distributed storage system and a purpose-built query engine.
Aurora can automatically scale both compute and storage resources based on the workload, allowing it to handle larger datasets and higher traffic volumes.

RDS uses a traditional master-slave replication model for high availability and data durability. Aurora, on the other hand, uses a different architecture called a "shared storage model" that replicates data across multiple Availability Zones. This enables Aurora to provide faster fail-over, instant crash recovery, and continuous backups without performance degradation.

Replication and Fail-over:
RDS supports both synchronous and asynchronous replication for high availability and disaster recovery. Aurora, on the other hand, replicates data across multiple instances within a cluster, providing faster replication and automatic fail-over with minimal data loss.

RDS uses standard storage options like Amazon EBS (Elastic Block Store) for database storage. Aurora, on the other hand, uses a distributed storage system called Aurora Storage, which is designed for high performance and durability. Aurora Storage is self-healing and automatically replicates data across multiple storage nodes.

Aurora tends to have a higher cost compared to traditional RDS instances due to its enhanced performance and scalability features. However, the higher cost is often offset by the potential savings in terms of reduced maintenance efforts and improved performance.

Ultimately, the choice between AWS
RDS and Aurora depends on your specific requirements and use case. If you need compatibility with multiple database engines or have specific needs for Oracle or SQL Server, RDS provides a broader range of options. On the other hand, if you require higher performance, scalability, and advanced features for MySQL or PostgreSQL workloads, Aurora is a compelling choice. It's recommended to evaluate your application's needs, performance requirements, and budget to determine the most suitable option.


Popular posts from this blog

MySQL InnoDB cluster troubleshooting | commands

Cluster Validation: select * from performance_schema.replication_group_members; All members should be online. select instance_name, mysql_server_uuid, addresses from  mysql_innodb_cluster_metadata.instances; All instances should return same value for mysql_server_uuid SELECT @@GTID_EXECUTED; All nodes should return same value Frequently use commands: mysql> SET SQL_LOG_BIN = 0;  mysql> stop group_replication; mysql> set global super_read_only=0; mysql> drop database mysql_innodb_cluster_metadata; mysql> RESET MASTER; mysql> RESET SLAVE ALL; JS > var cluster = dba.getCluster() JS > var cluster = dba.getCluster("<Cluster_name>") JS > var cluster = dba.createCluster('name') JS > cluster.removeInstance('root@<IP_Address>:<Port_No>',{force: true}) JS > cluster.addInstance('root@<IP add>,:<port>') JS > cluster.addInstance('root@ <IP add>,:<port> ') JS > dba.getC

MySQL slave Error_code: 1032 | MySQL slave drift | HA_ERR_KEY_NOT_FOUND

MySQL slave Error_code: 1032 | MySQL slave drift: With several MySQL, instance with master slave replication, I have one analytics MySQL, environment which is larger in terabytes, compared to other MySQL instances in the environment. Other MySQL instances with terabytes of data are running fine master, slave replication. But this analytics environment get started generating slave Error_code :1032. mysql> show slave status; Near relay log: Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_log_pos 5255306 Near master section: Could not execute Update_rows event on table <db_name>.<table_name>; Can't find record in '<table_name>', Error_code: 1032; Can't find record in '<table_name>', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log <name>-bin.000047, end_l

MySQL dump partition | backup partition | restore partition

MySQL dump Partition and import partition: $ mysqldump --user=root --password=<code> \ -S/mysql/<db_name>/data/<db_name>.sock --set-gtid-purged=OFF - -no-create-info \ <db_name> <table_name> --where="datetime between 'YYYY-MM-DD'  and 'YYYY-MM-DD'"  \  > /mysql/backup/<partition_name>.sql Where data type is bigint for partition, it will dump DDL for table also: $ mysqldump -uroot -p -S/mysql/mysql.sock --set-gtid-purged=OFF  \ <db_name> <table_name> --where="ENDDATE" between '20200801000000' and '20201101000000' \  > /mysql/dump/<schema_name>.<table_name>.sql   Alter table and add partitions which are truncated: Note: In following case partition 2018_MAY and 2018_JUN were truncated, so we need to reorganize the partition which is just after the desired partition. ALTER TABLE <table_name> REORGANIZE PARTITION 2018_JUL INTO ( PARTITION 2018_MAY VALUES LESS TH