fix (DMS): widen FC_Replicas RepID to BIGINT

[fstagni]

BEGINRELEASENOTES

*DMS
CHANGE: FileCatalogDB - FC_Replicas.RepID and FC_ReplicaInfo.RepID widened to BIGINT to avoid AUTO_INCREMENT exhaustion

*deployment

USE FileCatalogDB;
ALTER TABLE FC_Replicas MODIFY COLUMN RepID BIGINT NOT NULL AUTO_INCREMENT, ALGORITHM=COPY;
ALTER TABLE FC_ReplicaInfo MODIFY COLUMN RepID BIGINT NOT NULL AUTO_INCREMENT, ALGORITHM=COPY;

ENDRELEASENOTES

Summary

FC_Replicas.RepID was a signed INT (max 2147483647). InnoDB AUTO_INCREMENT values are never reused - not after DELETE, rollback, or failed/duplicate inserts - and the DFC churns them heavily (re-registrations attempting inserts that fail on the UNIQUE (FileID,SEID) key, replica migrations), so the counter runs ahead of the live row count until inserts start failing on large catalogs.

 CREATE TABLE FC_Replicas (
-    RepID INT AUTO_INCREMENT PRIMARY KEY,
+    RepID BIGINT AUTO_INCREMENT PRIMARY KEY,

 CREATE TABLE FC_ReplicaInfo (
-    RepID INTEGER NOT NULL AUTO_INCREMENT,
+    RepID BIGINT NOT NULL AUTO_INCREMENT,

The same change is applied to the reference schema in FileCatalogWithFkAndPsDB.sql.

Evidence

Exercised on a production instance (dbod-dfc, FileCatalogDB):

ALTER TABLE FC_Replicas
  MODIFY COLUMN RepID BIGINT NOT NULL AUTO_INCREMENT,
  ALGORITHM=COPY;

ALGORITHM=COPY is mandatory: data-type changes are not eligible for INPLACE/INSTANT, so this rebuilds the table and blocks concurrent DML for its duration. On very large FC_Replicas tables, pt-online-schema-change/gh-ost can be used instead. FC_ReplicaInfo.RepID stores the same IDs and must be widened too, otherwise it will start failing once RepID crosses 2^31.

Merge Danger

Door: two-way

Reverting the code change is trivial. Widening INT to BIGINT on live databases is not reversible without another table rebuild, but it is strictly safe: no values are lost, and existing INT-typed consumers of RepID receive a wider type transparently.

Blast Radius: FileCatalogDB schema