All database and operations configurations covered on this page apply to FastGPT v4.17.0.
What this category of data looks like
This category of data primarily originates from cell bank and seed lot records, culture and purification records, aseptic filling records, cleanroom environmental monitoring data, media fill simulation results, sterility test reports, and batch release documentation. Data sources cover cell banks and seed lots, process analysis systems, cleanroom monitoring, MES, LIMS, and equipment integrity testing. Data update frequencies include full batch records generated per production batch, real-time pushed cleanroom monitoring data, and environmental and equipment data updated per fixed monitoring schedules. A single batch record includes dozens of associated fields, such as culture temperature, filling cleanliness level, sterility test colony count, and all data is tied to a unique batch number.
Key constraints imposed on database and operations workflows
The batch-binding nature of data in this category requires the database to support fast associated queries for all related data using the batch number, to avoid excessive cross-table query latency. The high-concurrency write requirement for real-time monitoring data demands the database have high-throughput write performance. Historical data updated per monitoring schedules must be archived regularly to reduce online storage costs. Additionally, compliance requirements for data immutability require configuring audit tracking functions to ensure all operations are traceable. Furthermore, data errors can trigger severe safety risks, so the database must have complete backup and recovery mechanisms to prevent production release delays caused by data loss.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
MONGODB_URI | Configured as an authenticated replica set connection string, with SSL encryption enabled | Ensures secure transmission of sensitive data, supports multi-node redundancy to handle single-node failures |
PG_URL | Configured as a read-only replica connection address bound to LIMS and MES business data | Separates batch record write and trace query workloads, preventing query operations from occupying production database resources |
DB_MAX_LINK | 180–220 connections | Adapts to concurrent requests for batch record writes and real-time monitoring data, avoiding connection exhaustion |
REDIS_URL | Configured as a cache instance with RDB persistence and automatic backups every 15 minutes | Caches frequently accessed batch metadata and environmental monitoring snapshots, reducing database query latency |
| Data archiving rules | Automatically archive offline records older than 30 days per batch to low-cost storage | Adapts to historical data updated per monitoring schedules, reducing online storage costs |
| Concurrent request limit | Calibrated based on actual measurements | Adapts to concurrent push scenarios for cleanroom real-time monitoring data, avoiding resource overload |
Three common misconfigurations
- Symptom: Connection timeout errors occur after configuring
MONGODB_URI, with logs showingconnection refused. Cause: Authentication information for the replica set is not configured, or SSL encryption is not enabled, causing compliance verification to fail. - Symptom: Partial data loss occurs when concurrently pushing real-time monitoring data, with insufficient query result counts. Cause: The
DB_MAX_LINKparameter is not adjusted based on actual concurrent workloads, leading to database connection exhaustion and inability to create new connections. - Symptom: Some fields are empty when querying batch associated data via PG. Cause: The synchronization delay threshold for the read-only replica is not configured, leading to queries reading unsynchronized old data.
How to confirm the configuration is correct
- Execute a test script that simulates batch writing of a single batch record, verify that the database connection count does not exceed the
DB_MAX_LINKset value. - Access the cache interface, verify that query latency for frequently accessed batch metadata meets expected standards.
- Review the system audit log, confirm that all data write operations are fully recorded and cannot be modified.
- Simulate concurrent pushing of real-time monitoring data, check that no connection timeouts or data loss occur.
The values provided are common starting points and should be measured against the reader's own samples.