MySQL / InnoDB kernel

AliSQL 8.0.44-3 starts with the MySQL 8.0.44 server and InnoDB transaction stack. The DuckDB HTAP debut in 8.0.44-1 and the vector, historical-query, and binlog extensions in 8.0.44-2 build around that foundation. Version 8.0.44-3 adds binlog realtime replication (BRR) and updates the embedded DuckDB source.

One SQL endpoint, two workload paths

Application and MySQL client/driver
                 │
        MySQL protocol + SQL layer
                 │
       authentication · optimizer · binlog
                 │
         ┌───────┴────────┐
         │                │
      InnoDB           DuckDB
  transactions,      columnar scans,
  row storage,       joins, aggregation
  vector indexes

Path	Primary role	Data organization	Important AliSQL additions
MySQL / InnoDB	OLTP and transactional data	Row storage and B+tree indexes	Native vector index, historical reads, binlog commit optimizations, BRR
DuckDB	Analytics and archive-oriented queries	Columnar storage and vectorized execution	MySQL-facing SQL adaptation, conversion, replication, recovery, and resource controls

Applications retain the MySQL protocol and SQL entry point. That does not make every engine behavior identical: storage-engine capabilities, SQL semantics, replication requirements, and recovery paths still need feature-specific qualification.

Current kernel capability map

Capability	Engineering path	Default in 8.0.44-3	Main boundary
Native vector search	HNSW graph persisted in an InnoDB auxiliary table	vidx_disabled=ON	InnoDB only; indexed operations require READ COMMITTED
Native flashback	Historical InnoDB read view reconstructed from snapshot history and retained undo	Snapshot task OFF	Historical SELECT on InnoDB base tables; not a backup replacement
Persist Binlog Into Redo V2	Eligible binlog events enter the redo durability boundary, then background threads write the binlog	OFF	Strict transaction and 2PC eligibility checks; normal group commit is the fallback
Binlog Cache Free Flush	A finalized large transaction cache can become the next binlog file without a second large copy	OFF	Requires an eligible disk-backed cache; active DuckDB mode selects a dedicated commit path
Binlog realtime replication (BRR)	Transmit eligible events before source commit, with optional early apply on dedicated replica workers	Source/receiver switches OFF; binlog_realtime_apply_workers=0	Early apply requires GTIDs and parallel replication; not synchronous or guaranteed zero-lag replication
DuckDB storage engine	Columnar engine integrated through the MySQL server and storage-engine interfaces	duckdb_mode=NONE	Analytical use; MySQL compatibility is broad, not absolute

Binlog realtime replication (BRR)

Introduced in AliSQL 8.0.44-3, BRR overlaps source execution, transfer, and replica work for eligible DDL and large transactions. Final completion follows the source transaction outcome and GTID dependencies; it does not provide synchronous replication or a zero-lag guarantee.

• Disabled by default: source/receiver switches are OFF, and binlog_realtime_apply_workers=0.
• Large transactions: source-side binlog_cache_free_flush=ON, an eligible disk-backed cache, and no binlog transaction compression are required. The source-side transaction-size threshold defaults to 512 GiB.
• Early apply: requires GTIDs, parallel replication, nonzero BRR workers, replica_preserve_commit_order=OFF, and the documented channel restrictions. DuckDB Multi-Trx Batch requires replica_parallel_workers=0, so these modes cannot reuse the same settings unchanged.
• Monitoring: BRR_SOURCE_TRX_INFO, BRR_SENDER_TRX_INFO, BRR_REPLICA_INFO, and BRR status counters expose active work.

Read the 8.0.44-3 release summary and the Binlog Realtime Replication guide before enabling it.

Keep the boundaries visible

The feature flags are not cosmetic. They separate the mature MySQL/InnoDB baseline from execution paths that have their own topology, isolation, durability, or recovery prerequisites.

• Vector search keeps base rows and graph nodes under InnoDB transactions, but currently requires READ COMMITTED and serializes writers on the same vector table.
• Flashback depends on snapshot generation plus undo retention. Enabling its query gate alone does not create recoverable history.
• Binlog in Redo optimizes eligible smaller transaction caches and falls back per transaction when a guard fails.
• Free Flush targets spilled large transaction caches and has a different eligibility model.
• BRR moves eligible replication work before source commit; final completion still depends on the source transaction result and GTID dependencies.
• DuckDB introduces its own table storage and analytical replication path; keep latency-sensitive transactional writes on InnoDB.

Read the implementation by path

• DuckDB analytics — SQL adaptation, columnar execution, replica topology, and operational limits.
• Native vector search — HNSW persistence, cache layers, SQL, parameters, and concurrency.
• Native flashback — snapshot generation, undo retention, historical reads, and recovery boundaries.
• Binlog optimization — how Binlog in Redo and Free Flush alter eligible commits and when they fall back.
• Quick start — build the source and verify each path independently.

Open source and managed service are different operating contexts

Alibaba Cloud RDS MySQL provides managed versions of several AliSQL capabilities, but product versions, topology, parameter names, defaults, and support policy can differ. Use this site and the repository wiki for a self-managed source build; use RDS product documentation for an RDS instance.

Authoritative references

• AliSQL source repository
• AliSQL 8.0.44-3 release notes
• Binlog Realtime Replication guide
• MySQL 8.0 reference manual