Author: admin yep

Laravel Schema Sentinel by Ahtesham at Broadway Web Service detects schema drift— to help identify when your actual database no longer matches your migrations. It builds a shadow database from your migrations, diffs it against the live schema, and can generate a corrective migration when the two diverge.

• Deep drift detection — audits tables, columns, data types, nullability, defaults, indexes, and foreign keys
• Cross-environment comparison — verify local migrations match staging or production
• Auto-generated migrations — create corrective migrations with interactive review
• Visual dashboard — built-in Livewire component for database health monitoring
• Pre-migration guard — automatically block php artisan migrate if drift is detected
• And more…

Detecting Drift

The core command runs your migrations into a temporary shadow database, then compares that shadow against your live connection:

php artisan schema:drift

It checks tables, columns, data types, nullability, defaults, indexes, and foreign keys. Running with --strict also flags columns or tables present in the live database that have no corresponding migration.

Generating a Fix

When drift is found, you can have Sentinel generate a migration to close the gap:

php artisan schema:drift --fix --interactive

Interactive mode walks you through each detected difference before writing anything. A --sql flag skips file creation and prints the migration code to the terminal for review.

Cross-Environment Comparison

You can point the diff at a different environment’s database connection instead of your local one:

php artisan schema:drift --compare-env=staging

This uses the named connection from your config/database.php, so you can verify your local migrations match what’s deployed to staging or production before running them.

Programmatic API

A Sentinel facade exposes the same diff as a DTO, which you can use in controllers, Livewire components, or admin dashboards:

use Sentinel\SchemaSentinel\Facades\Sentinel;
 
$diff = Sentinel::check(strict: true);
 
return response()->json([
 'in_sync' => !$diff->hasDifferences(),
 'drift' => $diff->toArray(),
]);

The package also ships a Blade-embeddable Livewire component for a visual health dashboard, though it only renders in local environments:

<livewire:sentinel-database-health />

The package supports Laravel 11.x through 13.x. You can find Laravel Schema Sentinel on GitHub.

The latest release of the Percona Operator for MySQL, 1.1.0, is here. It brings point-in-time recovery, incremental backups, zstd backup compression, configurable asynchronous replication retries, and a set of stability fixes. This post walks through the highlights and how they help your MySQL deployments on Kubernetes.

 

Percona Operator for MySQL 1.1.0

Running stateful databases on Kubernetes means your backup and recovery story has to be airtight. A full nightly backup is fine, until the DBA drops a table at 2 PM and you’re looking at 14 hours of lost work. Or until your storage bill grows faster than your actual data because every backup is a full copy.

Percona Operator for MySQL 1.1.0 addresses exactly these pain points. This release lands point-in-time recovery, incremental backups, and backup compression: three features that together give you finer recovery control, faster backup jobs, and meaningfully smaller storage footprints. It also brings configurable asynchronous replication retries and a set of stability fixes that harden everyday operations.

This is a community-driven release. Nearly every headline feature in 1.1.0 traces back to user feedback: issues raised on forums.percona.com, JIRA tickets filed by operators in production, and recurring questions from teams running MySQL on Kubernetes at scale. The operator is fully open source, runs on any CNCF-conformant Kubernetes distribution (GKE, EKS, OpenShift, or bare metal), and costs nothing to run. Let’s walk through what’s new.

In this post, you’ll learn about:

• Point-in-Time Recovery (Tech Preview)
• Incremental Backups (Tech Preview)
• Backup Compression with zstd
• Asynchronous replication retry configuration
• Other improvements

Point-in-Time Recovery (Tech Preview)

A backup restores your cluster to the moment the backup was taken, but incidents rarely respect your backup schedule. With point-in-time recovery now available in Tech Preview, you can restore your MySQL cluster to any specific timestamp or GTID position, not just to a backup snapshot.

The operator continuously collects binary logs and stores them alongside your full and incremental backups. When a restore is needed, it starts from the nearest full backup, applies incremental backups, and then replays binary logs forward to the exact point in time you specify. PITR works identically across asynchronous and group replication topologies, so you don’t need to restructure your setup to take advantage of it.

A timestamp-based restore targets the exact moment before an incident:

When you need finer precision than timestamp-based recovery (for example, replaying right up to the transaction immediately before a bad UPDATE), use pitr.type: gtid and specify the exact GTID position.

This is especially useful after an accidental DROP TABLE or a bad application deploy mid-day: you recover to the moment just before the event, not to last night’s snapshot.

See the documentation for the full configuration reference.

Note: PITR is marked Tech Preview in 1.1.0 and is not recommended for production workloads yet. Try it in staging and share your feedback on the community forum.

 

Incremental Backups (Tech Preview)

Full backups work, but they come with a cost: every job copies your entire dataset, consuming time, I/O, and storage whether or not much has changed since the last run. Incremental backups solve this by capturing only the changes since the previous backup.

The Operator integrates incremental backup support, powered by Percona XtraBackup, across all supported backup storage backends (S3-compatible, GCS, Azure Blob Storage). Both scheduled and on-demand backup jobs can run incrementally. When you trigger a restore, the Operator reconstructs the full state by chaining the base backup with the subsequent incremental sets, so you don’t manage that complexity manually.

This helps when you need:

• • Faster daily backup jobs on large datasets that change slowly

• • Lower storage and egress costs per backup cycle

• • Tighter recovery windows without sacrificing backup frequency

• • Less I/O pressure on the primary during backup jobs

The backup manifest lives in deploy/backup/backup.yaml. Note the commented type and incrementalBaseBackupName fields: they are exactly how you switch a backup to incremental mode and point it at a previous backup as its base.

Set type: full to take a base backup, then for each subsequent incremental set type: incremental.

Note: Incremental backups are also marked Tech Preview in 1.1.0. You can learn more about this feature in a separate blog post: Incremental backups in Percona Kubernetes Operator for MySQL

 

Backup Compression with zstd

Even without incremental backups, you can now shrink your full backup size significantly. The operator adds support for zstd compression, which compresses backup data with Percona XtraBackup before it streams to object storage.

Smaller transfers mean faster uploads, lower egress costs, and less object storage consumption, especially relevant when your cluster is in a different region from your storage bucket. The operator handles decompression transparently during restore, so your recovery workflow stays the same.

You can enable compression globally by configuring XtraBackup in mysql.configuration on the Custom Resource:

Or enable it per on-demand backup via containerOptions:

Full details are in the compressed backups documentation. Percona XtraBackup’s zstd compression reference covers the algorithm-level tradeoffs if you want to tune further. One known limitation in 1.1.0: lz4 compression is not yet supported pending an upstream resolution.

 

Asynchronous Replication Retry Configuration

In asynchronous replication topologies, transient network issues can stall replication threads on a MySQL Pod. Previously, reconnection behavior was fixed. Now you can tune it via the Custom Resource using two environment variables:

• ASYNC_SOURCE_RETRY_COUNT: the number of reconnection attempts before the replica gives up
• ASYNC_SOURCE_CONNECT_RETRY: the delay in seconds between reconnection attempts

This is useful in environments with higher network latency or less reliable connectivity between zones. You can give the replica more time to recover without manual intervention.

A related improvement (K8SPS-69): the readiness probe now fails if replication threads stop on a MySQL Pod. This prevents Kubernetes from routing traffic to a replica that has quietly fallen behind, a common source of stale reads that were difficult to detect without custom monitoring.

 

Other Improvements

Operational polish shipped alongside the headline features:

• • Readiness probe catches stopped replication (K8SPS-69): the readiness probe now fails when replication threads stop, so Kubernetes stops routing traffic to replicas that have quietly fallen behind.

• • Automatic PVC removal on async replication restore (K8SPS-215): old PVCs are cleaned up automatically when restoring in async replication mode, one less manual step after a restore.

• • Scheduled backups paused on unhealthy clusters (K8SPS-435): backups no longer kick off against a degraded cluster, preventing partial or corrupted backup sets.

• • Structured error handling (K8SPS-595): invalid storage configurations now surface as structured error messages instead of Operator panics.

• • Status events reclassified (K8SPS-601): normal status transitions emit as Normal event types instead of warnings, cutting noise in kubectl describe output and alerting pipelines.

• • HAProxy file descriptor handling (K8SPS-666): file descriptor management in the HAProxy container is optimized so connection counts are no longer silently capped on busy clusters.

The release also ships improved documentation: OpenShift installation instructions now include the full OLM procedure, an Operator upgrade tutorial for OpenShift has been added, and Helm documentation covers customized parameters and custom release naming.

 

Conclusion

Percona Operator for MySQL 1.1.0 delivers meaningful improvements to every phase of the database lifecycle on Kubernetes. PITR and incremental backups in Tech Preview give you a path toward granular recovery without full-backup overhead. Compression with zstd reduces your storage and egress costs immediately. Configurable async replication retries and a batch of stability fixes harden the Operator for production workloads at scale. These features are in this release because the community asked for them.

We encourage you to read the full release notes and try the new features. Feedback is welcome on the GitHub repository, the Community Forum, or JIRA.

 

Try It Out