Manticore Search 29.0.2 focuses on operational improvements for sharded and distributed tables: OPTIMIZE TABLE now works natively across distributed and sharded tables, SHOW TABLE SETTINGS supports sharded tables, and long shard writes use heartbeat-based rolling timeouts instead of oversized static timeouts. Vector search gains configurable file access modes (buffered file vs mmap) for columnar and secondary indexes, plus batched full-precision rescoring for columnar KNN. The release also fixes several reliability issues: a crash from stale memory addresses during concurrent RT optimization and KNN construction, inconsistent optimize_cutoff handling for KNN compaction, a backup freeze failure path, MySQL Connector/J initialization in Buddy, HTML boundary preservation in highlighting, a use-after-free in SHOW THREADS, a hang in EXPLAIN QUERY on template tables, and memory retention in distributed-agent request handling. A mixed-version upgrade note warns that 29.0.0 changed the internal SHARD_WRITE API and cluster protocol, so remote shard agents must be upgraded before coordinators, and all replication peers before initiating SST.
Table of contents
Upgrade NotesNative OPTIMIZE for Distributed and Sharded TablesSharded-table Settings Are VisibleLong Shard Writes No Longer Depend on Oversized TimeoutsMore Control in Vector SearchReliability FixesGet Manticore Search 29.0.2Need Help or Want to Connect?Questions this post answers
What changed in Manticore Search 29.0.0 that affects upgrading a cluster with native sharded tables or replication?
Manticore Search 29.0.0 changed the internal SHARD_WRITE API and cluster protocol to carry heartbeat data, which affects mixed-version deployments using native sharded-table writes or replication SST. Remote shard agents must be upgraded before the coordinators that write to them, and all replication peers must be upgraded before initiating SST. Standalone nodes need no special handling, and downgrades are possible but coordinators should be downgraded before agents. daily.dev surfaces rollout details like this for teams planning a careful cluster upgrade.
How does Manticore Search prevent long shard writes from timing out during HNSW vector index builds?
Manticore Search 29.0.2 sends heartbeat replies over the same connection during long shard writes, and each valid heartbeat renews agent_query_timeout as a rolling lease, keeping the connection alive while the operation makes progress. This removes the need to set an artificially large agent_query_timeout to cover normal RAM chunk flush or HNSW build time on sharded vector tables. Track infra-level fixes like this on daily.dev when tuning timeout settings for vector search clusters.
Can OPTIMIZE TABLE be run directly on a distributed or sharded table in Manticore Search?
Yes, as of Manticore Search 29.0.2, OPTIMIZE TABLE with OPTION sync=1, cutoff=1 compacts distributed and sharded tables directly, applying the cutoff across every local RT component and configured remote mirror synchronously. Previously operators had to run optimization against each physical RT table separately; failures on remote targets are now reported rather than hidden behind a successful local response. daily.dev helps engineers keep up with database maintenance changes like this OPTIMIZE TABLE update.