Shard spam_logs table

Action Required: Classify the spam_logs table

To properly configure the spam_logs 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 spam_logs table from the following:

A. Org-level with sharding key

This is for data that belongs to an entire organization.

• Action:
  • Set gitlab_schema: gitlab_main_cell.
  • 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.

2. Complete the Task

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

Documentation

• Schema selection guidelines
• Sharding key definition
• desired_sharding_key backfill process

Tasks

• Add organization_id to spam_logs table !207058 (merged)
• Enforce a foreign key constraint on spam_logs.user_id and clean up orphan rows !212667 (merged)
• Add NOT NULL constraint to spam_logs.user_id !212667 (merged) !214701 (merged)
• Add foreign key constraint to spam_logs.user_id and remove spam_logs records referencing non-existent users.id !212667 (merged) !214701 (merged)
• Backfill organization_id via spam_logs.user_id !210030 (closed) !212438
• Add NOT NULL constraints to organization_id !212438
• Add sharding_key: configuration to spam_logs.yml table definition.