Fallback provides data protection at the table level by automatically storing a copy of each permanent data row of a table on a different or “fallback” AMP.
If an AMP fails, Analytics Database can access the fallback copy and continue operation. If you cluster your AMPs, fallback also provides for automatic recovery of the down AMP once you bring it back online.
Define fallback using the CREATE/ALTER TABLE commands. Fallback-protected tables occupy twice the permanent space as non-fallback tables and require twice the I/O for inserts, updates and deletes. However, the advantages in continued operation and data integrity are well worth the space.
You can define fallback for the following:
- Primary data table
- Secondary index subtable
- Join index of any type, including aggregate join index
- Hash index
- Databases
- Users
Fallback is beneficial because it does the following:
- Permits access to table data when an AMP is offline.
- Protects the accessibility and integrity of your data if it becomes unavailable due to a software error.
- Adds a level of data protection beyond disk array RAID.
- Automatically applies changes to the offline AMP when it is back online.
You cannot use the NO FALLBACK option and the NO FALLBACK default on platforms optimized for fallback.