Backups Snapshots

 Backups

- full data backup, takes long time, difference  in actual data between data at start and end, can be stored anywhere, could be restored anywhere 
Snapshots 
- point in time picture of server, quick, but only could be stored in same VM/cloud where it was taken, specific to cloud vendor, could be used to restore in case of data loss quickly, works by storeing metadata and change log of block storage  

Amazon RDS provides two different methods for backing up and restoring your DB instance(s) automated backups and database snapshots (DB Snapshots).

Amazon RDS provides two different methods for backing up and restoring your DB instance(s) automated backups and database snapshots (DB Snapshots). When restored new endpoint created

Auto backups (7days storage, up to 35) enables point-in-time recovery of your DB instance. When automated backups are turned on for your DB Instance, Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs. Causes IO latency during backup, but if we use multi AZ, no latency. Latest restorable time within 5 mins DB Snapshots are user-initiated and enable you to back up your DB instance in a known state as frequently as you wish, and then restore to that specific state at any time.

DB Snapshots are user-initiated and enable you to back up your DB instance in a known state as frequently as you wish, and then restore to that specific state at any time.

For example, suppose that you have the automated backup of a DB instance taken at 04:00 UTC today, and you must perform a point-in-time restore at 06:15 UTC. In this case, the instance is restored from the backup that's created at 04:00 UTC. Then, the transaction logs until 06:16 UTC are applied to the restored instance to complete the point-in-time restore process.

  • If you enabled automatic backups on your source instances, then it's best practice to take manual snapshots at regular intervals to avoid a large number of delta changes from piling up and decrease the recovery point objective.

Multi-AZ DB instance deployment. - one standby instance , but doesn’t serve reads. The primary DB instance is synchronously replicated across Availability Zones to a standby replica. can have increased write and commit latency compared to a Single-AZ deployment. This can happen because of the synchronous data replication that occurs. You might have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use Provisioned IOPS (input/output operations per second) for fast, consistent performance

On failover, takes 2 min or more to restore. DNS is changed(ip address changes), so set Jvm ttl to 60 second.

Multi-AZ DB cluster deployment. - multiple standby instance , serve reads
Cluster /writer/reader/instance endpoints. DML and writes to writer endpoints. Cluster endpoints to administer, ETL operations. Instance endpoint  connects to specific instance and used to troubleshoot issues, query tuning issues in specific instance.
Writes have low latency compared to db instance deployment. Uses engine based replication, replica lag could occur if writes are heavy. Use Flow control (throtting) to mitigate replica lag, lag could affect reader promotion during failover, failover could take 35 sec

Comments

Post a Comment

Popular posts from this blog

ECS

  https://medium.com/boltops/ gentle-introduction-to-how- aws-ecs-works-with-example- tutorial-cea3d27ce63d Cluster creation : Template type - Networking only (Fargate), EC2 type Roles Task execution IAM role , this role helps to pull images from your docker registery Task Role - for accessing AWS services  Service creation Type - Fargate/EC2 Type - Replica No of task instances  Min, Max num of healthy instances  Service Auto Scaling is made possible by a combination of the Amazon ECS, CloudWatch, and Application Auto Scaling APIs. Services are created and updated with Amazon ECS, alarms are created with CloudWatch, and scaling policies are created with Application Auto Scaling. Application Auto Scaling turns off scale-in processes while Amazon ECS deployments are in progress. However, scale-out processes continue to occur, unless suspended, during a deployment. Target tracking, step, schedule scaling supported More complex explanation  https://docs.aws. amazon.com/AmazonECS/latest/ d
Read more

RDS

    Multi-AZ DB instance deployment . - one standby instance , but doesn’t serve reads.  The primary DB instance is synchronously replicated across Availability Zones to a standby replica.  can have increased write and commit latency compared to a Single-AZ deployment. This can happen because of the synchronous data replication that occurs. You might have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use Provisioned IOPS (input/output operations per second) for fast, consistent performance Multi-AZ DB cluster deployment . - multiple standby instance ,  serve reads
Read more

DKIM and OCI Email

DKIM stands for Domain Key Identified Mail. It allows an organization to take responsbility to sign emails sent from its domains. It uses pub/private key to sign and allow receiver to verify the authenticity of the email. It prevent mail spoofing and proliferation attacks. OCI email delivery allows to configure DKIMs for email domains.When DKIM is created, it generates a CNAME record to be used in email domain configuraiton. Email Configuration Create a User and generate SMTP Credentials for that user. This user/credentials is used to login to the SMTP server. Create an approved sender in the Email Domain. This will be the from address. Attach a DKIM to the sender/domain.
Read more