Fallback
Fallback is a Teradata Database feature that protects data in the case of an AMP vproc failure.
Fallback protection can be done at the table or database level.
It is especially useful in applications that require high availability.
Fallback protects your data by storing a second copy of each row of a table on a different AMP in the same cluster.
If an AMP fails, the system accesses the Fallback rows to meet requests.
Fallback provides AMP fault tolerance at the table level.
With Fallback tables, if one AMP fails, all data is still available. Users may continue to use Fallback tables without any loss of access to data.
During table creation or after a table is created, you may specify whether or not the system should keep a Fallback copy of the table.
If Fallback is specified, it is automatic and transparent.
Fallback guarantees that the two copies of a row will always be on different AMPs. If either AMP fails, the alternate row is still available on the other AMP.
Fallback will give effect on you system mainly on
Space:Need extra space for Fallback-protected tables in addition to the original database size.
RAID protection of Fallback-protected tables
Performance:Need twice the disk space for storage and twice the I/O required for INSERTs, UPDATEs, and DELETEs of rows in Fallback protected tables. The Fallback option does not require any extra I/O for SELECTS, as the system will read from one copy or the other, and the Fallback I/O will be performed in parallel with the primary I/O so there is no performance hit.
Fallback benefits:
How It Works:
Fallback is accomplished by grouping AMPs into clusters.
When a table is defined as Fallback-protected, the system stores a second copy of each row in the table on a "Fallback AMP" in the AMP cluster.
Below is a cluster of four AMPs. Each AMP has a combination of Primary and Fallback data rows:
Primary Data Row: A record in a database table that is used in normal system operation.
Fallback Data Row: The online backup copy of a Primary data row that is used in the case of an AMP failure.
Write: Each Primary data row has a duplicate Fallback row on another AMP. The Primary and Fallback data rows are written in parallel.
Read: When an AMP is down with a table that is defined as Fallback, Teradata will access the Fallback copies of the rows.
More Clusters: The diagram below shows how Fallback data is distributed among multiple clusters.
How It Handles Failures
If two physical disks fail in the same RAID 5 rank or RAID 1 mirrored pair, the associated AMP vproc fails. Fallback protects against the failure of a single AMP in a cluster.
If two AMPs in a cluster fail, the system halts and must be restarted manually, after the AMP is recovered by replacing the failed disk(s).
Reads: When an AMP fails, the system reads all rows it needs from the remaining AMPs in the cluster. If the system needs to find a Primary row from the failed AMP, it reads the Fallback copy of that row, which is on another AMP.
Writes: A failed AMP is not available, so the system cannot access any of that AMP's disk space. Copies of its unavailable primary rows are available as Fallback rows on the other AMPs in the cluster, and are updated there.
Replacement: Repairing the failed AMP requires replacing the failed physical disks and bringing the AMP online. Once the AMP is online, the system uses the Fallback data on the other AMPs to automatically reconstruct data on the newly replaced disks.
Fallback protection can be done at the table or database level.
It is especially useful in applications that require high availability.
Fallback protects your data by storing a second copy of each row of a table on a different AMP in the same cluster.
If an AMP fails, the system accesses the Fallback rows to meet requests.
Fallback provides AMP fault tolerance at the table level.
With Fallback tables, if one AMP fails, all data is still available. Users may continue to use Fallback tables without any loss of access to data.
During table creation or after a table is created, you may specify whether or not the system should keep a Fallback copy of the table.
If Fallback is specified, it is automatic and transparent.
Fallback guarantees that the two copies of a row will always be on different AMPs. If either AMP fails, the alternate row is still available on the other AMP.
Fallback will give effect on you system mainly on
Space:Need extra space for Fallback-protected tables in addition to the original database size.
RAID protection of Fallback-protected tables
Performance:Need twice the disk space for storage and twice the I/O required for INSERTs, UPDATEs, and DELETEs of rows in Fallback protected tables. The Fallback option does not require any extra I/O for SELECTS, as the system will read from one copy or the other, and the Fallback I/O will be performed in parallel with the primary I/O so there is no performance hit.
Fallback benefits:
- A level of protection beyond RAID disk array protection.
- Can be specified on a table-by-table basis to protect data requiring the highest availability.
- Permits access to data while an AMP is off-line.
- Automatically restores data that was changed during the AMP off-line period.
How It Works:
Fallback is accomplished by grouping AMPs into clusters.
When a table is defined as Fallback-protected, the system stores a second copy of each row in the table on a "Fallback AMP" in the AMP cluster.
Below is a cluster of four AMPs. Each AMP has a combination of Primary and Fallback data rows:
Primary Data Row: A record in a database table that is used in normal system operation.
Fallback Data Row: The online backup copy of a Primary data row that is used in the case of an AMP failure.
Read: When an AMP is down with a table that is defined as Fallback, Teradata will access the Fallback copies of the rows.
More Clusters: The diagram below shows how Fallback data is distributed among multiple clusters.
How It Handles Failures
If two physical disks fail in the same RAID 5 rank or RAID 1 mirrored pair, the associated AMP vproc fails. Fallback protects against the failure of a single AMP in a cluster.
If two AMPs in a cluster fail, the system halts and must be restarted manually, after the AMP is recovered by replacing the failed disk(s).
Reads: When an AMP fails, the system reads all rows it needs from the remaining AMPs in the cluster. If the system needs to find a Primary row from the failed AMP, it reads the Fallback copy of that row, which is on another AMP.
Writes: A failed AMP is not available, so the system cannot access any of that AMP's disk space. Copies of its unavailable primary rows are available as Fallback rows on the other AMPs in the cluster, and are updated there.
Replacement: Repairing the failed AMP requires replacing the failed physical disks and bringing the AMP online. Once the AMP is online, the system uses the Fallback data on the other AMPs to automatically reconstruct data on the newly replaced disks.
No comments:
Post a Comment