Weave Code
Ha Bundle Laravel Package
kibatic/ha-bundle
A Symfony bundle from Kibatic that brings high availability to Doctrine connections. It transparently fails over to a standby database server when the primary goes down, keeping your application online with minimal configuration and no changes to your existing queries.
Symfony profiler tools for High Availability applications
Frequently asked questions about Ha Bundle
- What does kibatic/ha-bundle actually do?
- It is a Symfony bundle that adds high availability behaviour to Doctrine database connections. When the primary database server becomes unreachable, it transparently fails over to a standby server instead of throwing connection errors on every request. It works by hooking into Symfony's dependency injection container and Doctrine DBAL's master/slave connection model, and it is designed to require no changes to your existing queries.
- Can I use kibatic/ha-bundle in a Laravel application?
- No. Despite being distributed on Composer and often listed alongside Laravel packages, it is a Symfony bundle and depends on Symfony bundle bootstrapping and Doctrine DBAL internals. Laravel uses Illuminate\Database over PDO, configures connections as arrays in config/database.php, and resolves them through DatabaseManager and connector classes, so none of the seams this bundle hooks into exist. Porting it would mean rewriting its bootstrapping and connection decoration, which is a build decision rather than a dependency adoption.
- What is the Laravel alternative to this bundle's database failover?
- The realistic path has three layers. First, use Laravel's native read/write connection configuration for static read/write splitting, which you already get for free. Second, if dynamic failover is genuinely required, write a small failover-aware connector or connection subclass that wraps PDO, owns health-check state, and exposes a read-only degraded mode. Third, and usually best, push the whole problem to infrastructure such as ProxySQL, MySQL Router, Amazon RDS or Aurora Multi-AZ, or Cloud SQL HA, so it is solved once for every service you run.
- How do I set up read/write splitting in Laravel without a package?
- Add read and write keys to a connection entry in config/database.php, listing the primary host under write and one or more replicas under read. Laravel routes SELECT statements to the read hosts and writes to the primary automatically, with the sticky option available if you need reads to follow a write within the same request. This handles the static half of the high availability problem with no third-party code at all, but it does not give you automatic failover when the primary disappears.
- Which Laravel, PHP and Doctrine DBAL versions does kibatic/ha-bundle support?
- There is no Laravel support at all, so no Laravel version matrix applies. Support is defined purely by its Symfony, PHP and Doctrine DBAL constraints, which you should read directly from the package's composer.json rather than assuming. Bundles of this vintage typically pin to older Doctrine DBAL majors, and DBAL has since shipped native primary/replica configuration, so verify the declared matrix intersects with your Symfony and DBAL versions before planning any upgrade path.
- How do I install and configure kibatic/ha-bundle in a Symfony application?
- You would install it with Composer, register the bundle in your kernel or bundles.php, and point its configuration at your primary and standby database connections. Because it decorates Doctrine's connection layer, the details that matter are which connection names it wraps and what timeout or retry budget it uses before declaring the primary dead. Confirm those settings against your own infrastructure before trusting it on a critical path.
- Is kibatic/ha-bundle safe to use in production?
- Treat it with caution. The project shows zero stars, zero dependents and no downstream signal, which means there is no evidence of production use and you would be the first adopter of critical-path failover logic. Failover code also fails in expensive ways, including routing writes to a lagging replica, split-brain during partial network partitions, connection storms when the primary recovers, and a so-called successful failover that leaves the application degraded with no telemetry. None of those behaviours are covered by visible tests.
- Should database failover fail closed or fail open for writes?
- For writes, it should fail closed. On primary loss the application should refuse writes outright or enter an explicitly defined degraded read-only mode rather than silently sending writes to a replica, which risks data loss and split-brain. This is the single most important question to ask of any failover layer, and it is not something you should infer from documentation alone. Write it down as a contract and test it deliberately before going live.
- Does kibatic/ha-bundle handle replica lag and MySQL versus PostgreSQL read-only semantics?
- That is not established by the overview and needs to be verified in the source. A sound implementation should distinguish a merely readable replica from one that is caught up enough to trust, and it should understand the difference between MySQL's read_only flag and PostgreSQL's read-only transaction semantics. It should also be clear about its detection mechanism, whether that is TCP or SELECT 1 polling, exception-driven retry, or connect-timeout heuristics, and the retry budget before it declares failure.
- Is kibatic/ha-bundle still maintained, and what does its MIT license require if I reuse the code?
- There is no downstream adoption signal, so treat maintenance as unproven and check the date of the last commit and whether the project is a fork before depending on it. The MIT license is permissive: if you lift code into your own Laravel connector, you must retain the copyright and permission notice. That is cheap to comply with, but it has to be done deliberately, so record the attribution in your repository.
Weaver
How can I help you explore Laravel packages today?