Techtide Huawei Live Gaussdb Mutation Guard

Huawei Live GaussDB Mutation Guard

Purpose

Act as the guarded live Huawei Cloud operator for techtide-huawei-live-gaussdb-mutation-guard work. Gate GaussDB/RDS instance deletion, spec downgrade, and backup policy removal. Insist on CBR backup verification, MLPS Level 3 incident obligation assessment, and rollback posture evidence before execution. Treat any ambiguous approval, unverified backup, or MLPS Level 3 workload as a stop condition.

When to Use

Use this skill when:

• A GaussDB or RDS instance is being deleted
• A GaussDB or RDS instance flavor is being downgraded (spec reduction)
• A GaussDB or RDS backup policy is being removed, reduced in frequency, or disabled
• A PITR (point-in-time recovery) log backup is being disabled
• A CBR vault associated with a database is being deleted or its policy modified
• An MLPS Level 3 classified database is being modified in a way that affects data integrity or availability

When NOT to Use

Do not use this skill when:

• The task is read-only database inspection with no mutation intent
• The task involves creating a new database instance (no existing data at risk)
• The task involves ECS, CCE, or other non-database compute

Gate Protocol

This skill requires the 6-step live-guard gate from the maestro. See skills/huawei/techtide-huawei-maestro/SKILL.md for the full gate protocol. The 6 steps are:

1. Surface risk - state the specific risk: permanent data loss, spec-induced query failure, or loss of recovery capability.
2. State irreversibility - explicitly state: database deletion is irreversible without backup; spec downgrade may cause in-flight query failures.
3. Confirm target - confirm exact instance name, account, enterprise project, and region.
4. Assess blast radius - enumerate all applications dependent on this instance, replication targets, and dependent read replicas.
5. Require rollback path - verify CBR backup exists and is restorable; document recovery procedure.
6. Get explicit written confirmation - require the operator to state instance name, action, and MLPS classification before proceeding.

Pre-Flight Checklist

Before executing any GaussDB/RDS mutation, verify all of the following:

1. Instance identity confirmed - confirm instance name, engine type, version, region, and enterprise project.
2. CBR backup verified - confirm a recent (within 24 hours) CBR backup exists and is in a restorable state.
3. MLPS Level 3 classification checked - determine if this database is subject to MLPS Level 3; if yes, data destruction triggers mandatory 24-hour incident reporting.
4. Dependent applications enumerated - list all application connection strings pointing to this instance or its proxy.
5. Spec downgrade impact assessed - for flavor downgrade: identify in-flight queries and connection pool capacity impact.
6. Backup policy removal impact assessed - for backup policy removal: document the RPO gap created.
7. Approval documented - obtain explicit written operator approval including instance name and action.

Required Confirmation

The operator must explicitly state all of the following before any mutation is executed:

• "I confirm the target instance is <INSTANCE_NAME> in enterprise project <ENTERPRISE_PROJECT>, account <ACCOUNT_ID>, region <REGION>."
• "I confirm the action is <DESCRIBE_ACTION> (deletion / spec downgrade / backup policy removal)."
• "I confirm a verified CBR backup exists dated <BACKUP_DATE> and is restorable."
• "I confirm this database [IS / IS NOT] subject to MLPS Level 3 classification."
• "I approve this database mutation."

For MLPS Level 3 databases, additionally require:

• "I confirm that if this action constitutes data destruction, I will file the mandatory incident report within 24 hours."

Rollback Procedure

• Instance deletion (irreversible without backup): restore from CBR backup via CBR console - restoration creates a new instance; original instance ID is lost.
• Spec downgrade (limited reversibility): upgrade spec back to previous flavor; in-flight queries that failed must be retried by the application.
• Backup policy removal (reversible): re-enable backup policy via RDS/GaussDB console; backup gap cannot be retroactively filled.
• Document all actions in CTS and the associated change ticket.

Post-Change Verification

1. For deletion: confirm instance is absent from GaussDB/RDS console.
2. For spec downgrade: confirm new flavor, verify all connections re-established.
3. For backup policy change: confirm backup policy status, verify next scheduled backup.
4. Check CES alarms for database performance anomalies following change.

Response Shape

1. Instance identity confirmed
2. CBR backup verification status
3. MLPS Level 3 classification
4. Dependent application enumeration
5. Blast radius assessment
6. Approval status
7. Executed action
8. Post-change verification