I made slight changes to the Debezium UI example for local demo purposes, here:
A distributed database is designed to withstand outages to a good degree. However, you should also maintain backups in case of “oops” scenarios like a dropped table.
I recently put together a platform to demo a handful of scenarios related to YugabyteDB cross-cluster replication.
Here’s a very quick way to set up YugabyteDB on your Mac for functional testing. It assumes you already have Homebrew installed.
Audit logging is essential for tracking the “who, what, when, and where” of database access and changes, supporting both security and compliance requirements. It helps organizations know who accessed or modified data, schemas, roles, or grants.
At DSS 2021, I provided a comprehensive orientation to monitoring YugabyteDB, focusing on how to interpret and leverage built-in metrics for operational visibility.
I recently did an upgrade of 200+ nodes of Cassandra across multiple environments sitting behind multiple applications using the cstar tool. I chose the cstar tool because, out of all automation options, it has topology awareness specific to Cassandra. I will share my experience with this upgrade, including observations and surprises, as well as a walk-through of the process using a Cassandra cluster provisioned in Docker.
PostgreSQL offers multiple backup options, including logical backups with pg_dump and pg_dumpall, and physical backups with pg_basebackup. Regular backups and testing restore procedures are essential for disaster recovery. Continuous archiving and point-in-time recovery provide additional protection and flexibility for critical database environments.
Upgrading large Cassandra clusters is simplified with cstar, which discovers cluster topology and executes commands in a topology-aware manner. This reduces downtime and risk, and practical tips include using verbose output and ensuring all nodes are up before starting. cstar’s automation and resilience make it ideal for complex, large-scale operations.
Security vulnerabilities in PostgreSQL related to the search_path setting can allow malicious users to inject trojan-horse functions or objects. Remediation includes removing the public schema from the default search_path and restricting object creation in public. Practical commands and best practices help secure PostgreSQL installations against these exploits.