When you drop and re-create a replication slot on the Writer instance of your RDS PostgreSQL database, it should not directly impact the Reader instance if the Reader is not actively using those replication slots.

Replication slots in PostgreSQL are primarily used to track which WAL (Write-Ahead Log) segments need to be retained for logical replication consumers. In your case, these slots are being used by Airbyte for CDC (Change Data Capture).

For standard RDS PostgreSQL Multi-AZ deployments, the physical replication between the Writer and Reader instances operates independently from the logical replication slots you've created for Airbyte. The Writer-Reader replication uses a different mechanism than the logical replication slots.

However, there are a few considerations to be aware of:

1. In newer PostgreSQL versions (starting with PostgreSQL 17 and RDS for PostgreSQL 17), there's a feature for automatic synchronization of logical replication slots from primary to standby servers, but this requires specific configuration and wouldn't apply to older versions.

2. For RDS Multi-AZ DB clusters (which is different from standard Multi-AZ deployments), logical replication slots created on the Writer are asynchronously copied to each Reader instance in the cluster. In this case, dropping and recreating slots on the Writer would propagate to the Readers.

3. If your Reader instance went down for reasons related to disk space, it's worth investigating if WAL retention due to replication slots might have contributed to the issue, even if the Reader wasn't directly using those slots.

In summary, for standard RDS PostgreSQL deployments, dropping and recreating replication slots on the Writer should not directly impact a Reader instance that isn't using those slots. However, for Multi-AZ DB clusters, changes to replication slots on the Writer do propagate to the Readers.
Sources
Managing logical slot synchronization for RDS for PostgreSQL - Amazon Relational Database Service
Setting up PostgreSQL logical replication with Multi-AZ DB clusters for Amazon RDS - Amazon Relational Database Service

Having a Regional cluster with "Multi-AZ: 2 Zones" doesn't necessarily mean you have an RDS Multi-AZ DB cluster. You likely have instance with multi-AZ deployment and the read replica of the same instance in same or different availability zone, which is different from a Multi-AZ DB cluster.

Here's the key difference:

Regional cluster with Multi-AZ (2 Zones):

In this configuration, you have a primary writer instance in one Availability Zone (AZ) with a standby instance in another AZ for high availability. Additionally, you can create one or more read replicas, each with its own standby in a different AZ. The primary writer and each read replica have their own unique endpoints for direct connection. However, the standby instances (both for the writer and the read replicas) don't have accessible endpoints as they're not actively serving traffic unless promoted.

• Replication Slots Behaviour in a Regional cluster setup:

• Replication slots are maintained only on the Writer instance
• Readers don't replicate the replication slots from the Writer
• This is why you see 0 slots when querying the Reader

RDS Multi-AZ DB cluster:

The Multi-AZ DB cluster architecture employs a configuration with one Writer instance and two Reader instances, distributed across three distinct Availability Zones (AZs) for maximum availability. This architecture specifically uses dedicated Writer and Reader DB instances, The cluster provides three types of endpoints for different purposes: a Writer endpoint specifically for write operations, a Reader endpoint for read operations, and Instance endpoints for direct access to specific instances. This design ensures high availability, automatic failover capabilities, and efficient read scaling while maintaining data consistency through synchronous replication.

• Replication Slots Behavior in a Multi-AZ DB cluster setup:

• Replication slots are maintained only on the Writer instance
• By default, two replication slots are automatically created on the Writer instance for Reader replication.
• Readers don't replicate the replication slots from the Writer
• Here also you can see 0 slots when querying the Reader

So, it's completely normal and expected that your Reader instance shows 0 replication slots while the Writer has 3. The replication slots you created for Airbyte (CDC) only need to exist on the Writer instance where the actual changes are being captured.

To verify your cluster type, you can:

1. Check the AWS Console
2. Look for "DB cluster" vs "DB instance" in the configuration
3. Check if you have separate endpoints for Writer and Reader (Regional cluster) or a cluster endpoint (Multi-AZ DB cluster)