[ aws . rds ]

backtrack-db-cluster

Description

Backtracks a DB cluster to a specific time, without creating a new DB cluster.

For more information on backtracking, see Backtracking an Aurora DB Cluster in the Amazon Aurora User Guide.

Note

This action only applies to Aurora MySQL DB clusters.

See also: AWS API Documentation

See ‘aws help’ for descriptions of global parameters.

Synopsis

  backtrack-db-cluster
--db-cluster-identifier <value>
--backtrack-to <value>
[--force | --no-force]
[--use-earliest-time-on-point-in-time-unavailable | --no-use-earliest-time-on-point-in-time-unavailable]
[--cli-input-json | --cli-input-yaml]
[--generate-cli-skeleton <value>]

Options

--db-cluster-identifier (string)

The DB cluster identifier of the DB cluster to be backtracked. This parameter is stored as a lowercase string.

Constraints:

  • Must contain from 1 to 63 alphanumeric characters or hyphens.

  • First character must be a letter.

  • Can’t end with a hyphen or contain two consecutive hyphens.

Example: my-cluster1

--backtrack-to (timestamp)

The timestamp of the time to backtrack the DB cluster to, specified in ISO 8601 format. For more information about ISO 8601, see the ISO8601 Wikipedia page.

Note

If the specified time isn’t a consistent time for the DB cluster, Aurora automatically chooses the nearest possible consistent time for the DB cluster.

Constraints:

  • Must contain a valid ISO 8601 timestamp.

  • Can’t contain a timestamp set in the future.

Example: 2017-07-08T18:00Z

--force | --no-force (boolean)

A value that indicates whether to force the DB cluster to backtrack when binary logging is enabled. Otherwise, an error occurs when binary logging is enabled.

--use-earliest-time-on-point-in-time-unavailable | --no-use-earliest-time-on-point-in-time-unavailable (boolean)

A value that indicates whether to backtrack the DB cluster to the earliest possible backtrack time when BacktrackTo is set to a timestamp earlier than the earliest backtrack time. When this parameter is disabled and BacktrackTo is set to a timestamp earlier than the earliest backtrack time, an error occurs.

--cli-input-json | --cli-input-yaml (string) Reads arguments from the JSON string provided. The JSON string follows the format provided by --generate-cli-skeleton. If other arguments are provided on the command line, those values will override the JSON-provided values. It is not possible to pass arbitrary binary values using a JSON-provided value as the string will be taken literally. This may not be specified along with --cli-input-yaml.

--generate-cli-skeleton (string) Prints a JSON skeleton to standard output without sending an API request. If provided with no value or the value input, prints a sample input JSON that can be used as an argument for --cli-input-json. Similarly, if provided yaml-input it will print a sample input YAML that can be used with --cli-input-yaml. If provided with the value output, it validates the command inputs and returns a sample output JSON for that command.

See ‘aws help’ for descriptions of global parameters.

Examples

To backtrack an Aurora DB cluster

The following backtrack-db-cluster example backtracks the specified DB cluster sample-cluster to March 19, 2018, at 10 a.m.

aws rds backtrack-db-cluster --db-cluster-identifier sample-cluster --backtrack-to 2018-03-19T10:00:00+00:00

This command outputs a JSON block that acknowledges the change to the RDS resource.

Output

DBClusterIdentifier -> (string)

Contains a user-supplied DB cluster identifier. This identifier is the unique key that identifies a DB cluster.

BacktrackIdentifier -> (string)

Contains the backtrack identifier.

BacktrackTo -> (timestamp)

The timestamp of the time to which the DB cluster was backtracked.

BacktrackedFrom -> (timestamp)

The timestamp of the time from which the DB cluster was backtracked.

BacktrackRequestCreationTime -> (timestamp)

The timestamp of the time at which the backtrack was requested.

Status -> (string)

The status of the backtrack. This property returns one of the following values:

  • applying - The backtrack is currently being applied to or rolled back from the DB cluster.

  • completed - The backtrack has successfully been applied to or rolled back from the DB cluster.

  • failed - An error occurred while the backtrack was applied to or rolled back from the DB cluster.

  • pending - The backtrack is currently pending application to or rollback from the DB cluster.