Fix: Remove tablespace missing errors from blocking instance startup

The previous fix tried to filter tablespace errors by database name, but this
was still blocking instance startup for valid scenarios where:
- Selected database files are present
- Other databases referenced in ibdata1 are missing (expected for partial restore)
- Instance is ready with force recovery mode

KEY INSIGHT: If the MySQL socket exists, the instance is running and ready for
mysqldump. Missing tablespace errors are NOT blocking issues - mysqldump will
either succeed (if selected database is intact) or fail with its own error.

SOLUTION: Only check for TRULY CRITICAL errors:
   Memory allocation failures
   Plugin initialization failures
   Redo log corruption
   Page corruption

  ✗ REMOVED: Missing tablespace checks (not truly critical)

This allows selective database restoration to work correctly when:
1. User restores only selected database files
2. ibdata1 contains references to databases that weren't restored
3. Instance starts successfully (socket exists)
4. mysqldump can access and dump the selected database

The show_recovery_options() function already has smart detection for this case
and will provide appropriate guidance if the dump actually fails.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
cschantz
2026-02-27 21:00:50 -05:00
parent 6e4df51501
commit bc38011963
+2 -20
View File
@@ -1090,6 +1090,7 @@ check_innodb_errors() {
# CRITICAL error patterns that ALWAYS fail (not specific to any database) # CRITICAL error patterns that ALWAYS fail (not specific to any database)
# These indicate fundamental InnoDB corruption or system issues # These indicate fundamental InnoDB corruption or system issues
# NOTE: Missing tablespaces are NOT included - instance can still work with force recovery
local critical_patterns=( local critical_patterns=(
"InnoDB: Corrupted" "InnoDB: Corrupted"
"InnoDB: Database page corruption" "InnoDB: Database page corruption"
@@ -1099,13 +1100,6 @@ check_innodb_errors() {
"InnoDB: Plugin initialization aborted" "InnoDB: Plugin initialization aborted"
) )
# DATABASE-SPECIFIC error patterns
# These only cause failure if they mention the selected database
local db_patterns=(
"InnoDB: Unable to open"
"InnoDB: Tablespace.*missing"
)
# If checking recent errors, only look at last 50 lines # If checking recent errors, only look at last 50 lines
local log_content local log_content
if [ "$check_recent" = "yes" ]; then if [ "$check_recent" = "yes" ]; then
@@ -1115,6 +1109,7 @@ check_innodb_errors() {
fi fi
# Check CRITICAL patterns first (always fail if found) # Check CRITICAL patterns first (always fail if found)
# These are truly blocking issues that prevent any recovery
for pattern in "${critical_patterns[@]}"; do for pattern in "${critical_patterns[@]}"; do
if echo "$log_content" | grep -qE "$pattern"; then if echo "$log_content" | grep -qE "$pattern"; then
local error_line=$(echo "$log_content" | grep -E "$pattern" | tail -1) local error_line=$(echo "$log_content" | grep -E "$pattern" | tail -1)
@@ -1123,19 +1118,6 @@ check_innodb_errors() {
fi fi
done done
# Check DATABASE-SPECIFIC patterns only if they mention the selected database
if [ -n "$selected_db" ]; then
for pattern in "${db_patterns[@]}"; do
# Create pattern that checks both for the error pattern AND the database name
# The error message will contain backticks like: `database_name`.`table_name`
if echo "$log_content" | grep -qE "$pattern.*\`${selected_db}\`"; then
local error_line=$(echo "$log_content" | grep -E "$pattern.*\`${selected_db}\`" | tail -1)
critical_errors+=("$error_line")
errors_found=$((errors_found + 1))
fi
done
fi
if [ -n "$errors_found" ] && [ "$errors_found" -gt 0 ]; then if [ -n "$errors_found" ] && [ "$errors_found" -gt 0 ]; then
print_error "InnoDB errors detected in $error_log:" print_error "InnoDB errors detected in $error_log:"
for err in "${critical_errors[@]}"; do for err in "${critical_errors[@]}"; do