Php Mysql Replication Laravel Package

Product Decisions This Supports

• Build vs. buy for change data capture (CDC). This package makes an in-house MySQL binlog consumer a credible option instead of standing up Debezium/Kafka Connect, Maxwell, or a managed service like AWS DMS. The v11.1.0 throughput gain (up to ~100% on some workloads) directly changes the capacity math in that comparison — fewer consumer processes per binlog stream, lower infra spend, same headroom.
• Event-driven features on an existing MySQL primary. Cache invalidation, search index sync, read-model/materialized-view refresh, audit trails, and outbound webhook/queue triggers can be sourced from the binlog rather than from application-level hooks — a roadmap-unlocking decision when you need changes that didn't originate in your Laravel app (batch jobs, admin SQL, other services).
• Scoping and blast radius. New databasesIgnore / tablesIgnore config lets a single replication reader target only the tables a feature cares about. That's a product decision enabler: one shared MySQL instance can serve multiple consumers without each one processing the whole write volume, and noisy/irrelevant tables can be excluded without forking the library.
• Schema-evolution risk tolerance. TableMapBuilder separates TABLE_MAP_EVENT column-metadata parsing from RowEvent. Cleaner separation around column metadata means DDL changes (added/reordered columns, widened types) are handled in one well-tested place rather than sprinkled through row handling — lowering the cost of shipping schema changes on a CDC-dependent feature.
• Operability and support ownership. The debug config dump is a small but real decision input: it shortens "why isn't this event firing" triage and reduces the on-call knowledge needed to own a replication pipeline.
• Multi-tenant / shared-schema architectures. Table-prefix or per-tenant schema layouts can be filtered at the reader, which affects whether you can offer per-tenant CDC without per-tenant infrastructure.

When to Consider This Package

Good fit when:

• The stack is PHP/Laravel and the team owns it; you want CDC without adding a JVM, Kafka, or a second operational platform.
• MySQL (or MariaDB) row-based binlog is already enabled, and you have (or can get) an account with REPLICATION SLAVE / REPLICATION CLIENT privileges.
• Throughput is modest-to-moderate and latency in the sub-second-to-seconds range is acceptable — this is a library, not a cluster; scaling is your problem (shard by schema, run multiple readers).
• You want the transformation logic in application code next to your domain models, not in a connector's config DSL.
• You need to consume changes you don't control at the application layer (other services, migrations, backfills).

Look elsewhere when:

• Managed MySQL restricts binlog access or retention (several DBaaS offerings limit log_bin retention or replication grants) — verify this before committing.
• You need exactly-once delivery, schema registry, cross-database joins, or heterogeneous source support: Debezium + Kafka (or a managed CDC service) is the safer buy.
• Write volume is high enough that a single PHP process per stream is the bottleneck and you'd need a partitioning/cluster story anyway.
• The team has no appetite for owning binlog position management, GTID handling, failover re-anchoring, and lag monitoring — that operational surface is real and permanent.
• Postgres or multi-engine sources are on the roadmap.

Specific to v11.1.0: it's a minor release — additive, no stated breaking changes. The throughput and filtering improvements are worth an upgrade evaluation; the opt-in useTableMapMetadata flag suggests a behavior toggle, so validate on a staging replica before rolling to production. Treat the "up to 100%" figure as workload-dependent and re-benchmark against your own event mix.

How to Pitch It (Stakeholders)

For executives: We can add real-time data flows (search sync, cache freshness, audit history, analytics feeds) by reading MySQL's own change log instead of building custom hooks into every feature and backfilling the gaps. This release roughly doubles the processing ceiling in tested scenarios and adds table-level filtering, so we cover the same use cases with less infrastructure and less noise. The realistic alternative — a managed CDC platform — carries licensing and a new operational stack. Recommendation: a scoped proof-of-concept on one non-critical pipeline to validate throughput and failover behavior against our actual schema before committing to the roadmap.

For engineering: v11.1.0 extracts TABLE_MAP_EVENT column-metadata handling into a TableMapBuilder and refactors RowEvent to consume it. That's the right seam — DDL and type-mapping edge cases now have one home, and it's where we'd add coverage for schema changes we care about. The new useTableMapMetadata, databasesIgnore, and tablesIgnore options let one reader subscribe narrowly, which cuts per-consumer volume and simplifies multi-tenant or shared-instance setups. The config dump helps on-call. Two asks before adoption: (1) confirm our MySQL tier permits binlog replication and what retention we get; (2) benchmark with our event mix, since the 100% figure is workload-dependent. We also own binlog position/GTID recovery and lag alerting — budget for that explicitly rather than discovering it during an incident.