I am doing unit testing, and the test case is: yb-admin-snapshot-schedule-test.
Now, I have a question to ask:
The following directories were downloaded from the specified gitlab address:
/opt/yb-build/ysql-sys-catalog-snapshots/initial_sys_catalog_snapshot_184.108.40.206_debug (or release)
Under this directory, the exported_tablet_metadata_changes and rocksdb/*.sst.sblock.0 files do not contain the pg_yb_tablegroup, pg_yb_migration, and the pg_yb_catalog_version.
However, the following directory will also be generated when building:
Under this directory, the exported_tablet_metadata_changes and rocksdb/*.sst.sblock.0 files are generated, why they should contain pg_yb_tablegroup, pg_yb_migration, pg_yb_catalog_version?
My main question now is why one of the two directories mentioned above, the exported_tablet_metadata_changes and rocksdb/*.sst.sblock.0 files needs to contain pg_yb_tablegroup, pg_yb_migration, pg_yb_catalog_version, but while the other one doesn’t contain them?
When starting the master and performing recovery operations, it needs to use pg_yb_tablegroup, pg_yb_migration, pg_yb_catalog_version or not needed?
Are you custom compiling and looking to contribute?
If yes, can you post on slack on #contributors channel?
When I login to the slack , an error is reported:
I’m just trying to make changes to the development experience, such as changing the files to pg_bi_tablegroup, pg_bi_migration, pg_bi_catalog_version.
However, after this modification, the test case cannot pass, and some errors will be reported. e.g. the pg_bi_migration, pg_bi_catalog_version cannot be found.
Therefore, I would like to learn about the specific processing logic through the questions asked above.
it is as follow：
Are there any requirements for email addresses? I’m using XXX@qq.com
These system tables were not present as of version 2.0.9 and were introduced in a later version. We did not have the tablegroups feature back then (hence no pg_yb_tablegroup), no ysql upgrade path (hence no pg_yb_migration) and the catalog version was tracked elsewhere (hence no pg_yb_catalog_version).
When a user upgrades from an old version that does not contain these tables to a newer version that has them, as part of ysql_upgrade (see Upgrade a deployment | YugabyteDB Docs) they get created - this ensures that upgraded clusters contain them.
For in-cluster recovery operations such as PITR, we don’t allow going back ysql versions. For e.g. if a user is at ysql version X+1 and they want to restore to a time in the past when the version was X, we explicitly disallow such cases and return an error to the user.
For an out of cluster backup/restore, we support restoring the backup from say a cluster running at version X to a cluster at version X+1 but not the other way i.e. not a backup taken on a cluster at version X+1 restored to a cluster at version X.
Thanks for your reply.
Excuse me, One more question:
When starting the master node, the system will automatically load the previously generated Initial System Catalog Snapshot files and load the metadata information therein into memory.
Is this operation the data obtained from the following directory had been generated when building?
And then, it will be provided to YSQL for management and query, right ?
By the way，when the data from the following directories will be used?
Yes, we ship this initial_sys_catalog_snapshot with every release, if you download a YugabyteDB tarball from the website and unpack it, you’ll find it. When master node is started, we use this snapshot to construct the on-disk sys catalog tablet that the master manages as well as load the relevant in-memory structures.
The 220.127.116.11 sys catalog snapshot is just for testing purposes; to simulate upgrade unit-tests that involve using the metadata of an old version in a cluster at a new version.
OK，I got it now.
Thanks very much.