No description
Find a file
jedarden 605be4cb07 P3.1 TaskStore trait + SQLite backend (tables 1-7) - Implementation complete
Implemented the TaskStore trait and SQLite backend for the first 7 tables:

1. tasks - Miroir task registry with JSON node_tasks field
2. node_settings_version - per-(index, node) settings freshness tracking
3. aliases - single and multi-target alias support with history
4. sessions - read-your-writes session pins
5. idempotency_cache - BLOB body_sha256 field for request deduplication
6. jobs - background job queue with claim expiration
7. leader_lease - advisory lock for leader election

Key implementation details:
- Idempotent migrations using CREATE TABLE IF NOT EXISTS
- Schema version tracking with single SELECT check
- WAL mode enabled for concurrent write support
- PRAGMA busy_timeout=5000 to prevent deadlocks
- JSON columns properly serialized/deserialized
- BLOB fields for binary data (SHA256 hashes)

All acceptance criteria met:
- cargo test -p miroir-core task_store::sqlite - all CRUD round-trips pass
- Opening existing DB skips migrations via schema version check
- Concurrent writes work without deadlock (WAL + busy_timeout)
- Table sizes fit within 100 MB task registry cache budget

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-13 18:15:39 -04:00
.beads Fix SQLite task store PRAGMA busy_timeout 2026-05-13 17:59:10 -04:00
charts/miroir Phase 0 (miroir-qon): Verification complete - foundation confirmed 2026-05-09 05:51:59 -04:00
coverage Phase 1 (miroir-cdo): Close bead - Core Routing complete 2026-05-09 11:38:45 -04:00
crates P3.1 TaskStore trait + SQLite backend (tables 1-7) - Implementation complete 2026-05-13 18:15:39 -04:00
docs Phase 3 (miroir-r3j): Task Registry + Persistence — Verification complete 2026-05-09 05:40:08 -04:00
notes P3.1 TaskStore trait + SQLite backend (tables 1-7) - Verification complete 2026-05-13 17:59:46 -04:00
.editorconfig Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
.gitignore Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
.needle-predispatch-sha Fix SQLite task store PRAGMA busy_timeout 2026-05-13 17:59:10 -04:00
Cargo.lock Phase 2 (miroir-9dj): Proxy + API Surface — Complete implementation 2026-05-09 12:08:28 -04:00
Cargo.toml Phase 0 (miroir-qon): Rust 1.88 upgrade + test infrastructure 2026-05-09 02:05:44 -04:00
CHANGELOG.md Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
clippy.toml Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
lcov.info Phase 1 (miroir-cdo): Core Routing - Final verification 2026-05-09 11:50:04 -04:00
LICENSE Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
README.md Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00
rust-toolchain.toml Phase 0 (miroir-qon): Rust 1.88 upgrade + test infrastructure 2026-05-09 02:05:44 -04:00
rustfmt.toml Add repo hygiene: LICENSE, CHANGELOG, .gitignore 2026-04-18 20:47:36 -04:00

Miroir

Multi-node Index Replication Orchestrator, Integrated Rebalancing

Miroir is a RAID-like orchestration layer for Meilisearch. It stripes a large index across a fleet of small-RAM Meilisearch nodes with a configurable replication factor, fans out search queries across all shards, and rebalances shard assignments when nodes are added or removed — all using the Meilisearch Community Edition.

The Problem

Meilisearch loads its entire index into memory-mapped LMDB files. A large index that exceeds a single server's available RAM cannot run on that server. The Enterprise Edition's native sharding is gated behind a commercial license. Miroir solves this without it.

How It Works

Client
  │
  ▼
Miroir Orchestrator
  ├── Write path: hash(doc_id) → assign to shard → write to R replicas
  ├── Read path:  scatter query to all shards → gather → merge ranked results
  └── Rebalance: on node add/remove → recompute assignments → migrate minimum shards

Meilisearch Nodes (N instances, each holding a subset of shards)
  node-0   node-1   node-2   ...   node-N

Replication Factor

Analogous to software RAID — configurable per deployment:

RF Redundancy Node failures tolerated Capacity
1 None (stripe only) 0 100% of fleet
2 One replica 1 per shard group 50% of fleet
3 Two replicas 2 per shard group 33% of fleet

Key Components

  • Orchestrator — proxy that handles shard routing, scatter-gather, result merging, and topology management
  • Shard router — consistent hash function (Rendezvous/HRW) mapping document IDs to node assignments; minimal reshuffling on topology change
  • Rebalancer — on node add/remove, recomputes assignments and migrates only the shards that changed owners; surviving replicas serve reads during rebuild
  • Result merger — normalizes and merges ranked result sets from multiple shards into a single coherent response

Status

Design phase. See docs/ for architecture detail.