No description
1adbb94c96
Verified that the TaskStore trait and SQLite backend for tables 1-7 from plan §4 are fully implemented and tested. Implementation locations: - TaskStore trait: crates/miroir-core/src/task_store/mod.rs (lines 45-296) - SQLite backend: crates/miroir-core/src/task_store/sqlite.rs (lines 57-1444) - Schema definitions: crates/miroir-core/src/task_store/schema.rs - Test suite: crates/miroir-core/src/task_store/sqlite_tests.rs All 7 tables implemented: 1. tasks - Miroir task registry (node_tasks as JSON) 2. node_settings_version - Per-(index, node) settings freshness 3. aliases - Atomic index aliases (single and multi-target, history as JSON) 4. sessions - Read-your-writes session pins 5. idempotency_cache - Write deduplication (body_sha256 as BLOB) 6. jobs - Work-queued background jobs (claim_expires_at logic) 7. leader_lease - Singleton-coordinator lease (advisory lock substitute) Key features verified: ✓ WAL mode enabled for concurrency ✓ PRAGMA busy_timeout = 5000 to prevent deadlocks ✓ Idempotent schema initialization with schema_version tracking ✓ JSON columns properly serialized/deserialized ✓ BLOB columns handled correctly ✓ All 14 tests passing (CRUD round-trips, concurrent writes, persistence) Acceptance criteria met: ✓ All CRUD operations round-trip correctly ✓ Opening existing DB doesn't re-run migrations ✓ Concurrent writes don't deadlock ✓ Table sizes fit within plan §14.2 budget No code changes required - implementation was already complete. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .beads | ||
| charts/miroir | ||
| coverage | ||
| crates | ||
| docs | ||
| notes | ||
| .editorconfig | ||
| .gitignore | ||
| .needle-predispatch-sha | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| clippy.toml | ||
| lcov.info | ||
| LICENSE | ||
| README.md | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
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.