Data Repository Expansion - Discrepancy in "Create the Buddy Projection and Mark the Cluster K-safety of 1" Step

Products

• Network Observability
• CA Performance Management

Issue/Introduction

When expanding a Data Repository (DR) cluster from 1 node to 3 nodes, the SQL generated in the "Create the Buddy Projection and Mark the Cluster K-safety of 1" step (specifically /tmp/migration_status.sql) may not match the manual template provided in the official TechDocs documentation. This discrepancy can lead to confusion regarding whether to proceed with manual DDL edits for the <schema>.migration_status table.

Environment

Performance Management 25.4.6

Cause

The documentation describes a manual procedural artifact from older versions where hand-stitched buddy projections were required. In current versions of Vertica, the database often automatically materializes valid buddy projections (e.g., *_b1) and achieves K-safety through its internal refresh and rebalance machinery

Resolution

Engineering has determined that the manual SQL edits described in the documentation are no longer needed if the database catalog already reflects a healthy state.

Verification Steps: Instead of forcing the generated SQL file to match the documentation, verify the following in the database catalog:

• Check Projections: Confirm that migration_status_super and migration_status_b1 exist and show is_super_projection = t and is_up_to_date = t.
  
  On any DR node, run adminTools, select connect to database and run:
  
  SELECT
       projection_schema,
       projection_name,
       is_super_projection,
       is_up_to_date
   FROM
       projections
   WHERE
       anchor_table_name = 'migration_status'
       AND projection_schema = '<schema>';
  
  Example output (schema name is dauser):
   dauser           | migration_status_b1    | t                   | t
   dauser           | migration_status_super | t                   | t

• Verify Rebalance: Ensure rebalance_operations shows no active executions, indicating the process is complete.
  
   SELECT
       node_name,
       operation_name,
       object_name,
       operation_status,
       is_executing
   FROM
       rebalance_operations
   WHERE
       is_executing = true;
   node_name | operation_name | object_name | operation_status | is_executing
  
  This shoudl return nothing
  
  
• Confirm K-Safety: Verify that K-safety has been successfully achieved 
  
  SELECT GET_DESIGN_KSAFE();

If these criteria are met, the database is in the correct state, you can proceed to the next steps