Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replication factor defaults to 3 #54

Closed
hengestone opened this issue Feb 14, 2018 · 4 comments
Closed

Replication factor defaults to 3 #54

hengestone opened this issue Feb 14, 2018 · 4 comments
Assignees
Labels
kind/bug This issue is a bug

Comments

@hengestone
Copy link

Trying to create a keyspace with replication factor=1 seems to change the value to 3:
cqlsh> CREATE KEYSPACE myapp WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = false;

Then Describe gives:
cqlsh> describe myapp; CREATE KEYSPACE myapp WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'} AND durable_writes = true;

Other CQL commands also seem to default to 3, e.g. on a cluster with rf=1, creating a table gives the error:
Not enough live tablet servers to create table with the requested replication factor 3. 1 tablet servers are alive.

@rkarthik007 rkarthik007 added the kind/bug This issue is a bug label Feb 14, 2018
@hengestone
Copy link
Author

As per @bmatican creating the cluster with ./bin/yb-ctl --replication_factor 1 from the beginning solves this problem.

@bmatican
Copy link
Contributor

Glad that helped @hengestone ! We have on our roadmap to integrate support for overrides at keyspace/table level (and we've had some previous interest in that too: #13), but for now, we just allow setting them at the level of the entire deployment...

@kmuthukk
Copy link
Collaborator

@bmatican - assigning this to you... perhaps we can close this, but open a new issue to support keyspace level overrides for settings like replication factor.

@bmatican
Copy link
Contributor

Closing this one, filed #149 for the override part.

mbautin pushed a commit that referenced this issue Jun 20, 2019
Fix syntax rule in UPDATE command
jasonyb pushed a commit that referenced this issue Mar 13, 2024
jasonyb pushed a commit that referenced this issue Jun 11, 2024
PG-144 : Changing planing counter name to sync with pg_stat_statment.
abhinab-yb pushed a commit to abhinab-yb/yugabyte-db that referenced this issue Nov 14, 2024
PG allows duplicated OIDs in different catalog tables. However, in Babelfish, we use PG's OID as OBJECT_ID in all system catalog views and it should be unique within a logical database. Duplicate OIDs can break SQL server tools, e.g., SSMS, as well as customer applications.

In PG/Babelfish, duplicate OIDs can occur in the following two cases:
- After MVU (Major Version Upgrade)
- After hitting OID wraparound

This commit is to prevent duplicate OIDs during MVU and consists of two parts:

First of all, from the old cluster, it finds the max OID in the 5 catalog tables: pg_extension, pg_authid, pg_enum, pg_class and pg_type. And then pass the max OID to the new cluster as a form of GUC, babelfishpg_tsql.dump_restore_min_oid. In the new cluster, set the nextOid greater than the max OID from the old cluster using GetNewObjectId_hook.

Secondly, in pg_upgrade.c, it skips the step of transferring the next OID from the old cluster to the new cluster.

Also note that the type of babelfishpg_tsql.dump_restore_min_oid is defined by DefineCustomStringVariable() to support UINT_MAX.

Extension PR: babelfish-for-postgresql/babelfish_extensions#693

Task: BABEL-3613
Signed-off-by: Jungkook Lee [email protected]
(cherry picked from commit 841cf4e2193afaeadea81916d9d4387c34c62130)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug This issue is a bug
Projects
None yet
Development

No branches or pull requests

4 participants