[Question posted by a user on YugabyteDB Community Slack]
Is there a way to set wal_level = logical instead of replica in YugabyteDB? I’m looking to implement CDC so I can synchronize other systems with the changes.
Note that YugabyteDB doesn’t reuse the PostgreSQL storage engine & replication mechanism, but has built its own. And it doesn’t support setting wal_level=logical.
Currently, CDC support is in the works https://github.com/yugabyte/yugabyte-db/issues/9019.
Related
[Question posted by a user on YugabyteDB Community Slack]
Is it possible to have the primary data cluster and read replica be at different versions?
primary data # 2.1 and replicate cluster # 2.8
Ideally, no. During software upgrades, temporarily different nodes can be on different releases. But in a steady state, the read-replica nodes should be the same version as the primary cluster.
With xCluster, where the two clusters are really independent clusters linked with an async replication channel, they can be on different releases for extended periods of time.
[Question posted by a user on YugabyteDB Community Slack]
I’m trying to understand the tolerance failure in YugabyteDB.
My scenario is as follows:
Universe is setup with primary data cluster and 1 read replica cluster, max_stale_read_bound_time_ms = 60.
And the primary data cluster got wipe out (lost all data).
Questions:
Would we be able to rebuild the primary data cluster with the read replica cluster?
Can the read replica cluster become the primary data cluster?
The answer is no to both.
xCluster is what you want to use for DR.
The design point for read-replicas in YugabyteDB is not for DR, but rather to bring data closer to where data is being read from. And read replicas have no yb-master. Without a yb-master, one cannot read from it.
[Question posted by a user on YugabyteDB Community Slack]
Is it possible to work with the Postgres tables using Spark-connector? Write and read to a Yugabyte Postgres?
Yes, it is possible to read and write in YugabyteDB through the JDBC Spark connector. You can follow the Spark documentation as is.
Because YugabyteDB is PostgreSQL-compliant most PostgreSQL connectors should work just fine.
[Question posted by a user on YugabyteDB Community Slack]
The docs on changing cluster config, indicate that, when changing yb-master cluster membership, yb-tserver tserver_master_addrs should be updated to reflect the latest list of nodes, but I don't see a clear indication of how to best do so. Is this only possible by terminating each yb-tserver process and rerunning it with a new command-line flag?
There is yb-ts-cli set_flag for updating flags during runtime.
In this case, the tserver learns the new master addresses at runtime by itself, you just need to update the yb-tserver config so it has the new masters if it gets restarted.
Also, string flags in general are not safe to change at runtime because they're not thread-safe.
Can I get some help in understanding the real difference between YSQL vs YCQL? Based on the documentation I understand that the current implementation of underlying storage for YUGABYTE is DOCS DB and uses RAFT for replication.
Based on this can I assume that YSQL vs YCQL the only difference is that we have triggers, stored procs? and SQL features in YSQL and not in YCQL?
Great question. The plan is that over time YSQL will have most of the features in YCQL, but that is not the case today. This is because there is significant work left to be done in YSQL to achieve parity, some of which is already in progress.
YSQL features
YSQL re-uses the upper half of PostgreSQL with a horizontally scalable lower half called DocDB. Thus, YSQL would support all PostgreSQL features - including stored procedures, triggers, common table expressions, extensions and foreign data wrappers (last feature is not yet done).
YCQL features not in YSQL
Here is a list of YCQL features not in YSQL.
Cluster awareness: The client drivers are cluster aware, meaning the clients can discover all nodes of the cluster given just one contact point. These client drivers also get notified of node add/remove and therefore apps do not need a load balancer to use a distributed cluster. There is on-going work to incorporate this functionality into YSQL as a part of jdbc-yugabytedb project.
Topology awareness: The client drivers are also topology aware, meaning they are notified of the regions/zones in which the various nodes of the cluster are deployed. They can perform operations such as reading from nearest region/datacenter.
Automatic data expiry: YCQL supports automatic expiry of data using the TTL feature - you can set a retention policy for data at a table or row level and the older data is automatically purged from the DB.
Collection data types: YCQL supports collection data types such as sets, maps, lists. Note that both YCQL and YSQL support JSONB which can be used to model the above though.
Cassandra API compatible YCQL is Cassandra API compatible, and therefore supports the Cassandra ecosystem projects. Examples include Spark and Kafka connectors, JanusGraph and KairosDB support, etc. Note that while these ecosystem integrations can be built on top of YSQL, it does not exist today and is a matter of prioritization.