Task: unify internal vitess table name formats

[shlomi-noach]

Today, Vitess recognizes these formats as internal names:

GC table names

• _vt_HOLD_6ace8bcef73211ea87e9f875a4d24e90_20200915120410
• _vt_PURGE_6ace8bcef73211ea87e9f875a4d24e90_20200915120410
• _vt_EVAC_6ace8bcef73211ea87e9f875a4d24e90_20200915120410
• _vt_DROP_6ace8bcef73211ea87e9f875a4d24e90_20200915120410

Online DDL table names

• _84371a37_6153_11eb_9917_f875a4d24e90_20210128122816_vrepl
• _4e5dcf80_354b_11eb_82cd_f875a4d24e90_20201203114014_gho
• _4e5dcf80_354b_11eb_82cd_f875a4d24e90_20201203114014_ghc
• _4e5dcf80_354b_11eb_82cd_f875a4d24e90_20201203114014_del
• _4e5dcf80_354b_11eb_82cd_f875a4d24e90_20201203114013_new

As well as pt-osc names like _table_old or __table_old. We ignore pt-osc names for the sake of this discussion.

In the list above we have two different format types, and three different lengths of tables. Compare:

_vt_HOLD_6ace8bcef73211ea87e9f875a4d24e90_20200915120410
_vt_PURGE_6ace8bcef73211ea87e9f875a4d24e90_20200915120410
_84371a37_6153_11eb_9917_f875a4d24e90_20210128122816_vrepl

The latter, longest table name, is 58 characters long. This leaves no room for default foreign key name suffix such as _ibfk_1. See https://github.com/vitessio/vitess/issues/14570.

We want to unify the internal naming format like so:

• A single pattern for all internal tables.
• A fixed length name. We can predict characters starting from [0] or from end of name.
• Name must not exceed 56 characters, leaving enough space for a two digit default name foreign key suffix such as _ibfk_12.
• Contain readable UUID. We could condense the UUID using 36 character encoding, but readability is important for generalk purpose debugging and just observations of the processes.
• Contain readable timestamp. Likewise, readability goes a long way.
• A functionality hint (what this tabe is used for).
• Hinting prefix
• Hinting suffix

Suggested format

The following is a 56 character length format:

_vt_hld_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_prg_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_evc_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_drp_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_vrp_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_gho_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_ghc_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_
_vt_del_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_

where:

• hld - GC HOLD state
• prg - GC PURGE state
• evc - GC EVAC state
• drp - GC DROP state
• vrp - Online DDL / vreplication table
• gho- gh-ost table
• ghc - gh-ost changelog table
• del - gh-ost deleted table

The prefix _vt_ suggests that this might be a vitess table, before we even validate the exact format. The suffix _ suggests this might be a vitess table, again before we fully validate.

Two version rollout

This will have to rollout over multiple versions:

• [x] version 19 will recognize this new format on top of existing formats, as internal table format, and all processes will recognize the relevant tables (e.g. tablegc will recognize _vt_drp_6ace8bcef73211ea87e9f875a4d24e90_20200915120410_ as a DROP table)
• [x] version 20 will actually start creating tables with the new naming.
• [ ] version 21 or later: stop recognizing the old formats.

The reason why we have to split this over 19 and 20 is that if we create e.g. a _vt_drp_... table in a PRIMARY, and the replica does not yet recognize that as a DROP table, then if the replica gets promoted as a new PRIMARY it will not handle the table correctly.

[shlomi-noach]

version 21 or later: stop recognizing the old formats.

Postponing the hard removal, keeping the soft removal of old format for a while longer (new tables created in new format, but old format is still respected).