Sharding Key Investigation for keys table

Status Update

The database schema changes for the keys table have been completed via !208105 (merged). The table has been classified as Organization-level (gitlab_main_org) with organization_id as the sharding key.

Completed Work

  • Added organization_id column to keys table
  • Created index on organization_id
  • Added foreign key constraint to organizations table
  • Updated db/docs/keys.yml with gitlab_schema: gitlab_main_org and sharding_key: organization_id
  • Added model association: belongs_to :organization
  • Removed sharding_key_issue_url from documentation

Remaining Work

The remaining application-level work is tracked in epic: &19679

Key remaining tasks:

  1. Backfill organization_id for existing records
  2. Add NOT NULL constraint to organization_id
  3. Handle deploy keys shared across projects
  4. Update application code to use organization_id
  5. Testing and validation
  6. Documentation updates

Original Investigation

Action Required: Classify the keys table

To properly configure the keys table, please choose the one classification below that best fits its data and purpose. This choice will determine the table's database schema and sharding key.

After selecting the best option, remove the sharding_key_issue_url and apply the corresponding configuration.

1. Choose a Classification

Select the most suitable option for the keys table from the following:

A. Org-level with sharding key ✅ SELECTED

This is for data that belongs to an entire organization.

  • Action:
  • Set gitlab_schema: gitlab_main_org.
  • Add the sharding_key or desired_sharding_key.
  • If the key doesn't yet meet not-null or foreign key requirements, you can add a temporary exception. Please link to a follow-up issue in a comment next to the exception.
  • See an example at db/docs/epics.yml.

B. Cell-local

This is for data related to cell-specific features.

  • Action:
  • Set gitlab_schema: gitlab_main_cell_local.
  • Ensure there are no foreign key references to or from organization-level tables.

C. User-related

This is for data that is strictly and exclusively owned by a user.

  • Action:
  • Set gitlab_schema: gitlab_main_user.
  • Confirm the table's data belongs only to users.

D. Cell settings

This is for configuration settings that are specific to a single cell.

  • Action:
  • Set gitlab_schema: gitlab_main_cell_setting.
  • Ensure there are no foreign key references to or from organization-level tables.

Note: gitlab_main_clusterwide has been deprecated. If you believe this is the correct classification, please consult the Tenant Scale group for alternatives.

2. Complete the Task

  1. Add this issue to the epic: &11670
  2. Review the documentation below for more details.

Documentation

References

Edited by Aboobacker MK