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 after you bring the AMP 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
- Databases
- Users
Fallback has the following benefits:
- Permits access to table data when an AMP is offline.
- Protects the accessibility and integrity of data that 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 back online.
You cannot use the NO FALLBACK option and the NO FALLBACK default on platforms optimized for fallback.