Percona Resources

Software
Downloads

All of Percona’s open source software products, in one place, to download as much or as little as you need.

Valkey Contribution

Product Documentation

Why Percona for MongoDB?

Why Percona for PostgreSQL?

Percona Blog

Percona Blog

Our popular knowledge center for all Percona products and all related topics.

Community

Percona Community Hub

A place to stay in touch with the open-source community

Events

Percona Events Hub

See all of Percona’s upcoming events and view materials like webinars and forums from past events

About

About Percona

Percona is an open source database software, support, and services company that helps make databases and applications run better.

Percona in the News

See Percona’s recent news coverage, press releases and industry recognition for our open source software and support.

Our Customers

Our Partners

Careers

Contact Us

Anil Joshi
I am Anil Joshi, and I work for Percona as a support engineer. I've worked with some well-known Open Source database technologies (MySQL/MariaDB, MongoDB, and Redis) for almost ten years. I am keenly interested in learning new databases and writing database content.

Automatic “Multi-Source” Async Replication Failover Using PXC Replication Manager

The replication  manager script can be particularly useful in complex PXC/Galera topologies that require Async/Multi-source replication. This will ease the auto source and replica failover to ensure all replication channels are healthy and in sync. If certain nodes shouldn’t  be part of a async/multi-source replication, we can disable the replication manager script there to tightly controlled the flow. Alternatively, node participation can be controlled by adjusting the weights in the percona.weight table, allowing replication behavior to be managed more precisely.

Using PXC Replication Manager to Auto Manage Both Source and Replica Failover in Galera-Based Environments

In this blog post, we will be discussing the PXC Replication Manager script/tool which basically facilitates both source and replica failover when working with multiple PXC clusters, across different DC/Networks connected via asynchronous replication mechanism. Such topologies emerge from requirements like database version upgrades, reporting or streaming for applications, separate disaster recovery or backup solutions, […]

Integrating Citus with Patroni: Sharding and High Availability Together

Citus is a PostgreSQL extension developed with the intention of sharding and distributing the data across multiple machines. It offers features like distributed tables, reference tables, schema-based sharding and columnar storage. We have already covered the basics of Citus and the initial setup part in some earlier blog posts: How To Scale a Single-Host PostgreSQL […]

MySQL Orchestrator Failover Behavior During Replication Lag

Managing farms of MySQL servers under a replication environment is very efficient with the help of a MySQL orchestrator tool. This ensures a smooth transition happens when there is any ad hoc failover or a planned/graceful switchover comes into action. Several configuration parameters play a crucial role in controlling and influencing failover behavior. In this […]

Deploying External Read Replica in MySQL InnoDB Cluster

Innodb Cluster or ClusterSet topologies already have secondary instances that can act as a failover for primary or also offload read requests. However, with MySQL 8.4, we now have the feasibility of adding a separate async replica to the cluster for serving various special/ad-hoc queries or some reporting purposes. This will also help offload read traffic away […]

Orchestrator (for Managing MySQL) High Availability Using Raft

As we know, Orchestrator is a MySQL high availability and replication management tool that aids in managing farms of MySQL servers. In this blog post, we discuss how to make the Orchestrator (which manages MySQL) itself fault-tolerant and highly available. When considering HA for the Orchestrator one of the popular choices will be using the Raft consensus. […]

How Network Splits/Partitions Impact Group Replication in MySQL

In this blog post, we will explore how network partitions impact group replication and the way it detects and responds to failures. In case you haven’t checked out my previous blog post about group replication recovery strategies, please have a look at them for some insight. Topology:

Scenario 1: One of the GR nodes […]

Effective Strategies for Recovering MySQL Group Replication From Failures

Group replication is a fault-tolerant/highly available replication topology that ensures if the primary node goes down, one of the other candidates or secondary members takes over so write and read operations can continue without any interruptions. However, there are some scenarios where, due to outages, network partitions, or database crashes, the group membership could be broken, or we end […]

Valkey/Redis Replication and Auto-Failover With Sentinel Service

In this Valkey blog post, I will demonstrate how we can set up a simple replication process among the Valkey nodes and then finally use some auto-failover mechanism with the help of the Valkey-sentinel tool. Replication (Master-Slave) Basically, we have two setups with the information below.

Now let’s prepare some basic configurations in file […]

Valkey/Redis Configurations and Persistent Setting of the Key Parameters

Since Valkey (a fork of Redis) is around the corner, I thought to write a short blog post about some of the configuration parts, mainly discussing how to dynamically change certain settings and persist those inside the configuration file. Disk persistence Let me start with a very important setting, which is “SAVE,” that helps in […]

Copying Alert Rules From One Percona Monitoring and Management Server to Another

Since Percona Monitoring and Management (PMM) 2.40.0, Grafana uses PostgreSQL instead of SQLite database to store users, dashboards, and other persistent data. This aids in getting some useful information related to [configured alerts] directly via querying from the Postgres backend. Sometimes we need to migrate only alert rules from one PMM server to another for […]