Relational Databases on AWS: Amazon RDS and Aurora

Transcript

1. Relational Databases on AWS Pierre GOUDJO Amazon RDS and Aurora
2. There are mainly two ways to run your database workloads on AWS
3. Fully Managed vs Self-Managed
7. Amazon RDS Supported database management systems
8. Instances
9. Instances • A DB instance is an isolated database environment running in the cloud. • A DB instance can contain multiple user-created databases • Amazon RDS supports access to databases using any compatible SQL client application • You can have up to 40 DB instances in an account with some limitations
10. Instances Instance classes • The instance class determines the CPU, memory capacity and network bandwidth of an RDS DB instance • Each instance class relates to an EC2 instance type • There is three types of instance classes • Standard (M instances) • Memory Optimised (X, R and Z instances) • Burstable Performance (T instances)
11. Instances Instance storage • Amazon RDS uses EBS volumes as underlying storage • 3 types of storages • General Purpose SSD: cost e ff ective, for various workloads • Provisioned IOPS SSD: for I/O intensive workload • Magnetic
12. Multi-AZ Deployment
13. RDS instances live inside an AZ
14. Multi-AZ deployment of RDS instances
15. Multi-AZ • Multi-AZ deployment aims to provide High-availability and failover support for DB instances • In Multi-AZ, RDS automatically provisions and maintains a synchronous standby replica in a di ff erent AZ • Standby instances are not used to scale database read • DB instances using Multi-AZ can have increased write and commit latency due to synchronous replication
16. Failover scenario in Multi-AZ deployment of RDS instances
17. Failover scenario in Multi-AZ deployment of RDS instances
18. Failover scenario in Multi-AZ deployment of RDS instances
19. Multi-AZ Notes • Standby replica automatically switches over to primary in case of disruption • Failover uses DNS to switch the primary and the standby replica • Failover times are typically 60–120 seconds • Developer should be cautious of DNS cache retention to avoid longer disruption
20. Read replica deployment
21. Read replica deployment
22. Read replica • Read replica are used to reduce the load on the primary DB instance • Really practical in heavy-read scenarios • Can’t be used to write data
23. Read replica can be used in Multi-AZ deployment of RDS instances
24. Cross-region read replica
25. Read replica Notes • Cross-region read replica doesn’t work on SQL server • On Oracle, there is two mode of read replica • Read-only: Default mode • Mounted: The replica doesn’t accept user connection • It is possible to promote a read replica to primary instance • For MySQL and MariaDB databases, it is possible to replicate a DB external to RDS
27. Security
28. Authentication • RDS support several ways to authenticate database users • Password-based authentication • IAM database authentication • Kerberos authentication
29. Data protection • RDS uses TLS connection to protect data in transit • It is possible to rotate SSL/TLS certi fi cate for optimum protection • It is possible to encrypt data on RDS instance via AES-256 encryption • RDS integrates with AWS KMS for key management
30. Snapshots • Backup of RDS instance can be created • The process can be either • Manual • Automated • The backup snapshots of a DB instance are incremental
31. Point-in-time recovery • You can restore a DB instance to a speci fi c point in time, creating a new DB instance • You can restore to any point within your backup retention period • RDS uploads transaction logs for DB instances to Amazon S3 every 5 minutes
32. Logging and monitoring • Amazon RDS integrates well with CloudWatch • Alarms • Real-time OS metrics • Performance insights • Amazon integrates well with CloudTrail Logs • Database Logs can be retrieved
33. Amazon RDS Proxy
34. RDS Proxy is a connection pooling proxy that allows your applications to share databases connections
35. RDS proxy with some AWS lambda
36. Amazon RDS Proxy • RDS Proxy is an alternative to PgBouncer, PgPool, ProxySql or HirakiCP • RDS Proxy is ideal in a serverless environment as it reduce the burden of connection management on the database • The price depends on the RDS instance type used by your database. The larger the database instance, the more you end up paying
37. RDS proxy during failover AWS claims that RDS Proxy improve failover times by 30%-60%
38. RDS Proxy eliminates the need to store database credentials anywhere in the code
39. AWS RDS on VMware
44. AWS RDS on VMware Advantages • Reduces operational overhead • Good fi rst step before migrating to RDS on AWS in heavy VMware utilisation scenario • Easy scaling of instances • Cloudwatch metrics • Automatic and manual backup of on-premises databases • Point-in-time recovery
45. AWS RDS on VMware Limitations • No Multi-AZ support • No read replica in another region support • Works only for MySQL, PostgreSQL, SQL Server • No encryption at rest • No replication with external databases
46. Amazon Aurora
47. Amazon Aurora is a fully managed relational database engine that's compatible with MySQL and PostgreSQL
49. • A RDBMS is made of multiple layers • For most RDBMS, these layers are tightly integrated Anatomy of a RDBMS
51. Typical Mirrored Architecture of RDBMS on RDS
52. Aurora tackles database scaling by decoupling the storage layer
54. Amazon Aurora Architecture
56. Aurora single master topology Up to 15 aurora nodes
57. Aurora multi-master topology
58. Aurora multi-master pro/cons Better use multi-master with a sharding architecture
59. Amazon Aurora Global Database Asynchronous replication
60. Amazon Aurora Global databases • An Aurora global database consists of one primary AWS Region where your data is mastered, and up to fi ve read-only secondary AWS Regions • Aurora replicates data to the secondary AWS Regions using dedicated infrastructure, with latency typically under a second • Aurora global databases doesn’t support • Multi-master clusters • Serverless v1 • Backtracking (Fast Point-in-time recovery)
61. Aurora serverless
62. Aurora Serverless • The capacity allocated to your Aurora Serverless v1 DB cluster seamlessly scales up and down based on the load generated by your client application • When it does need to perform a scaling operation, Aurora Serverless v1 fi rst tries to identify a scaling point, a moment when no queries are being processed • Aurora Serverless might not be able to fi nd a scaling point for the following reasons: • Long-running queries • In-progress transactions • Temporary tables or table locks