kennytm

if the stats field is nil during restore, it will just be skipped. https://github.com/pingcap/br/blob/458d542b19ca8563cac4322888063476cd050c4d/pkg/restore/client.go#L816-L826 missing stats won't prevent user accessing the data, just that the queries are not optimized. ANALYZE...

running "analyze table" requires scanning the tables again though, which is slow (esp. when restoring from an old backup where the `stats` are all missing)

my preference is: 4\. the option should be `--analyze` (default is true) which could be set to false for those who really can't wait 5\. no need to do version...

So we'll be changing how we backup stats, and also support system tables like RBAC info and global variables. 1. We will backup all relevant `mysql.*` tables via normal SST...

can we just remove the table rewrite rules? seems useless.

If the user can create an HMAC key and set a default project, they can reuse the s3:// protocol as illustrated in https://cloud.google.com/storage/docs/migrating#migration-simple.

The credentials blob is extremely long, see https://cloud.google.com/iam/docs/creating-managing-service-account-keys#creating_service_account_keys for a template. So option B looks like the only viable way.

There are currently two solutions we may choose: * **3.** Perform BR full backup regularly at some sparse interval, and use CDC to capture the incremental changes between two BR...

@tennix this has to be assigned to all TiKV nodes too, right?

Checking https://cloud.google.com/docs/authentication/production, looks like the Go part of BR already supports ADC (just don't pass the credentials-file), but the Rust part still expects a credentials blob. So it is mainly...