
MyDumper has consolidated its locking flags into a single unified option, --sync-thread-lock-mode, and introduced a new SAFE_NO_LOCK mode. Unlike the existing NO_LOCK mode which logs a warning and continues even when thread synchronization fails, SAFE_NO_LOCK implements a strict fail-fast policy: if binlog positions diverge among worker threads during initialization, the backup is immediately aborted rather than producing a silently inconsistent dump. The post breaks down all five available modes (AUTO, FTWRL, LOCK_ALL, GTID, NO_LOCK, and SAFE_NO_LOCK), explaining the trade-offs between locking impact and consistency guarantees, and provides guidance on when each mode is appropriate for production, staging, or restricted cloud environments.
Nguồn: https://www.percona.com/blog/mydumper-locking-mechanisms-revisited-introducing-safe_no_lock. 8sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.

MySQL 9.6 removed MD5(), SHA1(), and SHA() as native built-in SQL functions, moving them to an optional Legacy Hashing Component. The recommended migration path is to replace these with SHA2(), choosing an appropriate digest size (224, 256, 384, or 512) based on data sensitivity. Generated columns using legacy hash functions require schema changes before upgrading since the component-provided functions are loadable functions and cannot be used in generated column expressions. The post provides SQL queries to audit views, stored procedures, triggers, and events for legacy hash usage, along with a step-by-step upgrade plan and decision matrix. Installing the legacy component should be treated as a temporary compatibility measure with documented justification, especially in regulated environments where MD5/SHA-1 usage may trigger compliance findings.
An experimental MySQL 9.7 build called ducksdb-mysql-engine integrates DuckDB as a pluggable storage engine, allowing tables marked ENGINE=DuckDB to offload analytical queries to DuckDB's columnar engine while keeping the same MySQL connection and data. A custom pushdown_select hook (handlerton::pushdown_select) translates qualifying SQL to DuckDB SQL transparently, falling back to the normal row path when needed. TPC-H benchmarks at scale factor 10 show InnoDB timing out on 6 of 22 queries and taking 1317 seconds on the rest, while the DuckDB engine completes all 22 in ~15 seconds. At SF100 (600M rows), the engine remains correct on all 22 queries and stays close to native DuckDB performance, outperforming MariaDB's DuckDB integration on several heavy joins and loading data ~4x faster. The project is open source under GPLv2 and explicitly experimental.

MySQL 26.7 Early Access is the first Innovation release after MySQL 9.7 LTS, adopting a CalVer yy.mm versioning scheme. Key highlights include: more robust InnoDB undo log truncation using a header flag instead of a local file; internal InnoDB recovery and metadata infrastructure improvements (redo log, tablespace, MVCC/ReadView interfaces); a new Change Stream Applier for parallel replication with separate apply and commit progression, configurable via APPLIER_VERSION=2; Group Replication now defaults to the MYSQL communication stack with deprecation warnings for XCom options; post-quantum cryptography support (ML-KEM hybrid and pure algorithms) when built with OpenSSL 3.5+; upgrade/compatibility check progress reporting; and the Thread Pool Plugin now available in Community Server. The release is for evaluation only and not intended for production use.

A PHP internals RFC discussion proposes minimum supported version requirements for PHP 8.6, specifically requiring autoconf for source builds and MySQL 5.7.3 or MariaDB 10.2.4 for persistent connections. The change is tied to adding COM_RESET_CONNECTION support to PDO and mysqlnd, which makes persistent connection behavior more predictable. During discussion, a community member discovered a connection leak when using PDO::ATTR_PERSISTENT with older MySQL versions (5.5.x) against the proposed implementation — each request opened a new connection instead of reusing the persistent one. The RFC author confirmed the leak exists but considers it a bug in the implementation rather than a flaw in the RFC itself.
Percona Operator for MySQL 1.2.0 introduces three major features for production MySQL fleets on Kubernetes. Cross-site replication via a new PerconaServerMySQLClusterSet custom resource enables declarative InnoDB ClusterSet topologies spanning multiple clusters or regions, replacing hand-wired async replication. Encrypted backups use XtraBackup's xbcrypt component with keys stored in Kubernetes Secrets, supporting S3, GCS, and Azure targets. Automatic PVC storage scaling monitors disk usage and grows volumes when a configurable threshold is crossed, up to a defined ceiling, eliminating manual intervention. Additional day-two operation improvements are also included.

Mycli v2.0.0 is a major release of the MySQL command-line client with breaking changes. New features include fuzzy history search via fzf, integrated LLM support via a /llm command, shell-like query-result redirection operators, system keyring password storage, improved batch execution with checkpoint/resume and progress/ETA, enhanced auto-completion leveraging foreign keys, fuzzy completion/correction via RapidFuzz, and SSL modernization.

An RFC has been proposed for PHP 8.6 that introduces minimum supported version requirements: a minimum autoconf version for building PHP from source, and minimum database versions of MySQL 5.7.3 and MariaDB 10.2.4 when using persistent connections. The proposal is tied to adding COM_RESET_CONNECTION support to PDO and mysqlnd, which requires these minimum database versions to function correctly.

Bài viết giải thích cơ chế flushing trong InnoDB theo cách dễ hiểu cho người mới, bao gồm bốn loại flushing: background, adaptive, LRU và sync flushing. Nó cũng đề cập đến các khái niệm như dirty pages, checkpoint age và redo log thông qua những ví dụ tương tự đời thường, đồng thời cung cấp ba lệnh chẩn đoán thực tế để phát hiện vấn đề flushing. Ngoài ra, bài viết còn đưa ra các giải pháp cụ thể như điều chỉnh dung lượng redo log, tối ưu IO capacity và kích thước buffer pool.
Lập trình viên cần hiểu cơ chế flush của InnoDB để tối ưu hóa hiệu suất cơ sở dữ liệu, tránh tình trạng lag do log đỏ (redo log) và bộ nhớ cache không được quản lý hiệu quả, đặc biệt khi xây dựng ứng dụng yêu cầu độ tin cậy cao.