[HTML payload içeriği buraya]
30.4 C
Jakarta
Tuesday, May 12, 2026

Implement catastrophe restoration with Amazon Redshift


Amazon Redshift is a totally managed, petabyte-scale information warehouse service within the cloud. You can begin with only a few hundred gigabytes of information and scale to a petabyte or extra. This allows you to use your information to accumulate new insights for your online business and prospects.

The target of a catastrophe restoration plan is to scale back disruption by enabling fast restoration within the occasion of a catastrophe that results in system failure. Catastrophe restoration plans additionally permit organizations to verify they meet all compliance necessities for regulatory functions, offering a transparent roadmap to restoration.

This publish outlines proactive steps you’ll be able to take to mitigate the dangers related to sudden disruptions and ensure your group is healthier ready to reply and get better Amazon Redshift within the occasion of a catastrophe. With built-in options reminiscent of automated snapshots and cross-Area replication, you’ll be able to improve your catastrophe resilience with Amazon Redshift.

Catastrophe restoration planning

Any form of catastrophe restoration planning has two key parts:

  • Restoration Level Goal (RPO) – RPO is the utmost acceptable period of time for the reason that final information restoration level. This determines what is taken into account an appropriate lack of information between the final restoration level and the interruption of service.
  • Restoration Time Goal (RTO) – RTO is the utmost acceptable delay between the interruption of service and restoration of service. This determines what is taken into account an appropriate time window when service is unavailable.

To develop your catastrophe restoration plan, it’s best to full the next duties:

  • Outline your restoration targets for downtime and information loss (RTO and RPO) for information and metadata. Make sure that your online business stakeholders are engaged in deciding applicable targets.
  • Determine restoration methods to fulfill the restoration targets.
  • Outline a fallback plan to return manufacturing to the unique setup.
  • Take a look at out the catastrophe restoration plan by simulating a failover occasion in a non-production surroundings.
  • Develop a communication plan to inform stakeholders of downtime and its impression to the enterprise.
  • Develop a communication plan for progress updates, and restoration and availability.
  • Doc your entire catastrophe restoration course of.

Catastrophe restoration methods

Amazon Redshift is a cloud-based information warehouse that helps many restoration capabilities out of the field to deal with unexpected outages and decrease downtime.

Amazon Redshift RA3 occasion sorts and Redshift serverless retailer their information in Redshift Managed Storage (RMS), which is backed by Amazon Easy Storage Service (Amazon S3), which is very accessible and sturdy by default.

Within the following sections, we focus on the varied failure modes and related restoration methods.

Utilizing backups

Backing up information is a crucial a part of information administration. Backups shield towards human error, {hardware} failure, virus assaults, energy outages, and pure disasters.

Amazon Redshift helps two sorts of snapshots: computerized and handbook, which can be utilized to get better information. Snapshots are point-in-time backups of the Redshift information warehouse. Amazon Redshift shops these snapshots internally with RMS by utilizing an encrypted Safe Sockets Layer (SSL) connection.

Redshift provisioned clusters supply automated snapshots which might be taken routinely with a default retention of 1 day, which will be prolonged for as much as 35 days. These snapshots are taken each 5 GB information change per node or each 8 hours, and the minimal time interval between two snapshots is quarter-hour. The information change should be better than the overall information ingested by the cluster (5 GB occasions the variety of nodes). You may also set a customized snapshot schedule with frequencies between 1–24 hours. You should utilize the AWS Administration Console or ModifyCluster API to handle the time period your automated backups are retained by modifying the RetentionPeriod parameter. If you wish to flip off automated backups altogether, you’ll be able to arrange the retention interval to 0 (not advisable). For added particulars, check with Automated snapshots.

Amazon Redshift Serverless routinely creates restoration factors roughly each half-hour. These restoration factors have a default retention of 24 hours, after which they get routinely deleted. You do have the choice to transform a restoration level right into a snapshot if you wish to retain it longer than 24 hours.

Each Amazon Redshift provisioned and serverless clusters supply handbook snapshots that may be taken on-demand and be retained indefinitely. Guide snapshots will let you retain your snapshots longer than automated snapshots to fulfill your compliance wants. Guide snapshots accrue storage fees, so it’s essential that you just delete them while you not want them. For added particulars, check with Guide snapshots.

Amazon Redshift integrates with AWS Backup that can assist you centralize and automate information safety throughout all of your AWS providers, within the cloud, and on premises. With AWS Backup for Amazon Redshift, you’ll be able to configure information safety insurance policies and monitor exercise for various Redshift provisioned clusters in a single place. You may create and retailer handbook snapshots for Redshift provisioned clusters. This allows you to automate and consolidate backup duties that you just needed to do individually earlier than, with none handbook processes. To study extra about organising AWS Backup for Amazon Redshift, check with Amazon Redshift backups. As of this writing, AWS Backup doesn’t combine with Redshift Serverless.

Node failure

A Redshift information warehouse is a group of computing assets referred to as nodes.
Amazon Redshift will routinely detect and substitute a failed node in your information warehouse cluster. Amazon Redshift makes your alternative node accessible instantly and hundreds your most incessantly accessed information from Amazon S3 first to will let you resume querying your information as rapidly as attainable.

If this can be a single-node cluster (which isn’t advisable for buyer manufacturing use), there is just one copy of the info within the cluster. When it’s down, AWS wants to revive the cluster from the newest snapshot on Amazon S3, and that turns into your RPO.

We suggest utilizing at the very least two nodes for manufacturing.

Cluster failure

Every cluster has a frontrunner node and a number of compute nodes. Within the occasion of a cluster failure, you could restore the cluster from a snapshot. Snapshots are point-in-time backups of a cluster. A snapshot incorporates information from all databases which might be operating in your cluster. It additionally incorporates details about your cluster, together with the variety of nodes, node sort, and admin consumer title. When you restore your cluster from a snapshot, Amazon Redshift makes use of the cluster info to create a brand new cluster. Then it restores all of the databases from the snapshot information. Word that the brand new cluster is on the market earlier than all the information is loaded, so you’ll be able to start querying the brand new cluster in minutes. The cluster is restored in the identical AWS Area and a random, system-chosen Availability Zone, until you specify one other Availability Zone in your request.

Availability Zone failure

A Area is a bodily location world wide the place information facilities are positioned. An Availability Zone is a number of discrete information facilities with redundant energy, networking, and connectivity in a Area. Availability Zones allow you to function manufacturing purposes and databases which might be extra extremely accessible, fault tolerant, and scalable than could be attainable from a single information heart. All Availability Zones in a Area are interconnected with high-bandwidth, low-latency networking, over totally redundant, devoted metro fiber offering high-throughput, low-latency networking between Availability Zones.

To get better from Availability Zone failures, you should utilize one of many following approaches:

  • Relocation capabilities (active-passive) – In case your Redshift information warehouse is a single-AZ deployment and the cluster’s Availability Zone turns into unavailable, then Amazon Redshift will routinely transfer your cluster to a different Availability Zone with none information loss or software adjustments. To activate this, you could allow cluster relocation in your provisioned cluster by way of configuration settings, which is routinely enabled for Redshift Serverless. Cluster relocation is freed from price, however it’s a best-effort method topic to useful resource availability within the Availability Zone being recovered in, and RTO will be impacted by different points associated to beginning up a brand new cluster. This can lead to restoration occasions between 10–60 minutes. To study extra about configuring Amazon Redshift relocation capabilities, check with Construct a resilient Amazon Redshift structure with computerized restoration enabled.
  • Amazon Redshift Multi-AZ (active-active) – A Multi-AZ deployment permits you to run your information warehouse in a number of Availability Zones concurrently and proceed working in unexpected failure eventualities. No software adjustments are required to keep up enterprise continuity as a result of the Multi-AZ deployment is managed as a single information warehouse with one endpoint. Multi-AZ deployments scale back restoration time by guaranteeing capability to routinely get better and are supposed for purchasers with mission-critical analytics purposes that require the best ranges of availability and resiliency to Availability Zone failures. This additionally permits you to implement an answer that’s extra compliant with the suggestions of the Reliability Pillar of the AWS Nicely-Architected Framework. Our pre-launch assessments discovered that the RTO with Amazon Redshift Multi-AZ deployments is below 60 seconds or much less within the unlikely case of an Availability Zone failure. To study extra about configuring Multi-AZ, check with Allow Multi-AZ deployments in your Amazon Redshift information warehouse. As of writing, Redshift Serverless presently doesn’t help Multi-AZ.

Area failure

Amazon Redshift presently helps single-Area deployments for clusters. Nevertheless, you have got a number of choices to assist with catastrophe restoration or accessing information throughout multi-Area eventualities.

Use a cross-Area snapshot

You may configure Amazon Redshift to repeat snapshots for a cluster to a different Area. To configure cross-Area snapshot copy, it’s worthwhile to allow this copy function for every information warehouse (serverless and provisioned) and configure the place to repeat snapshots and the way lengthy to maintain copied automated or handbook snapshots within the vacation spot Area. When cross-Area copy is enabled for an information warehouse, all new handbook and automatic snapshots are copied to the required Area. Within the occasion of a Area failure, you’ll be able to restore your Redshift information warehouse in a brand new Area utilizing the newest cross-Area snapshot.

The next diagram illustrates this structure.

For extra details about learn how to allow cross-Area snapshots, check with the next:

Use a customized area title

A customized area title is simpler to recollect and use than the default endpoint URL supplied by Amazon Redshift. With CNAME, you’ll be able to rapidly route visitors to a brand new cluster or workgroup created from snapshot in a failover state of affairs. When a catastrophe occurs, connections will be rerouted centrally with minimal disruption, with out purchasers having to vary their configuration.

For prime availability, it’s best to have a warm-standby cluster or workgroup accessible that commonly receives restored information from the first cluster. This backup information warehouse might be in one other Availability Zone or in a separate Area. You may redirect purchasers to the secondary Redshift cluster by organising a customized area title within the unlikely situation of a whole Area failure.

Within the following sections, we focus on learn how to use a customized area title to deal with Area failure in Amazon Redshift. Make sure that the next stipulations are met:

  • You want a registered area title. You should utilize Amazon Route 53 or a third-party area registrar to register a website.
  • You must configure cross-Area snapshots in your Redshift cluster or workgroup.
  • Activate cluster relocation in your Redshift cluster. Use the AWS Command Line Interface (AWS CLI) to activate relocation for a Redshift provisioned cluster. For Redshift Serverless, that is routinely enabled. For extra info, see Relocating your cluster.
  • Be aware of your Redshift endpoint. You may find the endpoint by navigating to your Redshift workgroup or provisioned cluster title on the Amazon Redshift console.

Arrange a customized area with Amazon Redshift within the main Area

Within the hosted zone that Route 53 created while you registered the area, create data to inform Route 53 the way you need to route visitors to Redshift endpoint by finishing the next steps:

  1. On the Route 53 console, select Hosted zones within the navigation pane.
  2. Select your hosted zone.
  3. On the Information tab, select Create document.
  4. For File title, enter your most popular subdomain title.
  5. For File sort, select CNAME.
  6. For Worth, enter the Redshift endpoint title. Make sure that to offer the worth by eradicating the colon (:), port, and database. For instance, redshift-provisioned.eabc123.us-east-2.redshift.amazonaws.com.
  7. Select Create data.

  1. Use the CNAME document title to create a customized area in Amazon Redshift. For directions, see Use customized domains with Amazon Redshift.

Now you can connect with your cluster utilizing the customized area title. The JDBC URL can be just like jdbc:redshift://prefix.rootdomain.com:5439/dev?sslmode=verify-full, the place prefix.rootdomain.com is your customized area title and dev is the default database. Use your most popular editor to connect with this URL utilizing your consumer title and password.

Steps to deal with a Regional failure

Within the unlikely state of affairs of a Regional failure, full the next steps:

  1. Use a cross-Area snapshot to restore a Redshift cluster or workgroup in your secondary Area.
  2. Activate cluster relocation in your Redshift cluster within the secondary Area. Use the AWS CLI to activate relocation for a Redshift provisioned cluster.
  3. Use the CNAME document title from the Route 53 hosted zone setup to create a customized area within the newly created Redshift cluster or workgroup.
  4. Be aware of the Redshift endpoint’s newly created Redshift cluster or workgroup.

Subsequent, it’s worthwhile to replace the Redshift endpoint in Route 53 for obtain seamless connectivity.

  1. On the Route 53 console, select Hosted zones within the navigation pane.
  2. Select your hosted zone.
  3. On the File tab, choose the CNAME document you created.
  4. Underneath File particulars, select Edit document.
  5. Change the worth to the newly created Redshift endpoint. Make sure that to offer the worth by eradicating the colon (:), port, and database. For instance, redshift-provisioned.eabc567.us-west-2.redshift.amazonaws.com.
  6. Select Save.

Now while you connect with your customized area title utilizing the identical JDBC URL out of your software, you ought to be related to your new cluster in your secondary Area.

Use active-active configuration

For business-critical purposes that require excessive availability, you’ll be able to arrange an active-active configuration on the Area stage. There are various methods to verify all writes happen to all clusters; a technique is to maintain the info in sync between the 2 clusters by ingesting information concurrently into the first and secondary cluster. You may also use Amazon Kinesis to sync the info between two clusters. For extra particulars, see Constructing Multi-AZ or Multi-Area Amazon Redshift Clusters.

Further issues

On this part, we focus on extra issues in your catastrophe restoration technique.

Amazon Redshift Spectrum

Amazon Redshift Spectrum is a function of Amazon Redshift that permits you to run SQL queries towards exabytes of information saved in Amazon S3. With Redshift Spectrum, you don’t should load or extract the info from Amazon S3 into Amazon Redshift earlier than querying.

When you’re utilizing exterior tables utilizing Redshift Spectrum, it’s worthwhile to be sure it’s configured and accessible in your secondary failover cluster.

You may set this up with the next steps:

  1. Replicate current S3 objects between the first and secondary Area.
  2. Replicate information catalog objects between the first and secondary Area.
  3. Arrange AWS Identification and Entry Administration (IAM) insurance policies for accessing the S3 bucket residing within the secondary Area.

Cross-Area information sharing

With Amazon Redshift information sharing, you’ll be able to securely share learn entry to stay information throughout Redshift clusters, workgroups, AWS accounts, and Areas with out manually transferring or copying the info.

When you’re utilizing cross-Area information sharing and one of many Areas has an outage, it’s worthwhile to have a enterprise continuity plan to fail over your producer and client clusters to reduce the disruption.

Within the occasion of an outage affecting the Area the place the producer cluster is deployed, you’ll be able to take the next steps to create a brand new producer cluster in one other Area utilizing a cross-Area snapshot and by reconfiguring information sharing, permitting your system to proceed working:

  1. Create a brand new Redshift cluster utilizing the cross-Area snapshot. Be sure to have appropriate node sort, node depend, and safety settings.
  2. Determine the Redshift information shares that had been beforehand configured for the unique producer cluster.
  3. Recreate these information shares on the brand new producer cluster within the goal Area.
  4. Replace the info share configurations within the client cluster to level to the newly created producer cluster.
  5. Affirm that the mandatory permissions and entry controls are in place for the info shares within the client cluster.
  6. Confirm that the brand new producer cluster is operational and the buyer cluster is ready to entry the shared information.

Within the occasion of an outage within the Area the place the buyer cluster is deployed, you’ll need to create a brand new client cluster in a special Area. This makes certain all purposes which might be connecting to the buyer cluster proceed to perform as anticipated, with correct entry.

The steps to perform this are as follows:

  1. Determine an alternate Area that’s not affected by the outage.
  2. Provision a brand new client cluster within the alternate Area.
  3. Present obligatory entry to information sharing objects.
  4. Replace the applying configurations to level to the brand new client cluster.
  5. Validate that each one the purposes are in a position to connect with the brand new client cluster and are functioning as anticipated.

For added info on learn how to configure information sharing, check with Sharing datashares.

Federated queries

With federated queries in Amazon Redshift, you’ll be able to question and analyze information throughout operational databases, information warehouses, and information lakes. When you’re utilizing federated queries, it’s worthwhile to arrange federated queries from the failover cluster as properly to forestall any software failure.

Abstract

On this publish, we mentioned numerous failure eventualities and restoration methods related to Amazon Redshift. Catastrophe restoration options make restoring your information and workloads seamless so you may get enterprise operations again on-line rapidly after a catastrophic occasion.

As an administrator, now you can work on defining your Amazon Redshift catastrophe restoration technique and implement it to reduce enterprise disruptions. It’s best to develop a complete plan that features:

  • Figuring out essential Redshift assets and information
  • Establishing backup and restoration procedures
  • Defining failover and failback processes
  • Imposing information integrity and consistency
  • Implementing catastrophe restoration testing and drills

Check out these methods for your self, and go away any questions and suggestions within the feedback part.


Concerning the authors

Nita Shah is a Senior Analytics Specialist Options Architect at AWS based mostly out of New York. She has been constructing information warehouse options for over 20 years and makes a speciality of Amazon Redshift. She is concentrated on serving to prospects design and construct enterprise-scale well-architected analytics and determination help platforms.

Poulomi Dasgupta is a Senior Analytics Options Architect with AWS. She is obsessed with serving to prospects construct cloud-based analytics options to unravel their enterprise issues. Exterior of labor, she likes travelling and spending time along with her household.

Ranjan Burman is an Analytics Specialist Options Architect at AWS. He makes a speciality of Amazon Redshift and helps prospects construct scalable analytical options. He has greater than 16 years of expertise in several database and information warehousing applied sciences. He’s obsessed with automating and fixing buyer issues with cloud options.

Jason Pedreza is a Senior Redshift Specialist Options Architect at AWS with information warehousing expertise dealing with petabytes of information. Previous to AWS, he constructed information warehouse options at Amazon.com and Amazon Gadgets. He makes a speciality of Amazon Redshift and helps prospects construct scalable analytic options.

Agasthi Kothurkar is an AWS Options Architect, and relies in Boston. Agasthi works with enterprise prospects as they remodel their enterprise by adopting the Cloud. Previous to becoming a member of AWS, he labored with main IT consulting organizations on prospects engagements spanning Cloud Structure, Enterprise Structure, IT Technique, and Transformation. He’s obsessed with making use of Cloud applied sciences to resolve complicated actual world enterprise issues.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles