When a GLPI SQL read replica is worth adding
A read replica is worth considering when a busy GLPI instance slows ticket work because reports, searches or large list views compete with writes on the primary database. A replica is a second MySQL or MariaDB server that receives changes from the primary and serves read queries. It does not make GLPI faster at writing tickets, assets or inventory updates, and it adds operational work that a single database does not carry. Before you add one, measure where the time goes. If the slowdown comes from undersized database memory, missing indexes or slow PHP processing, a replica will not fix it, and the tuning guidance for MySQL and MariaDB should come first.
Three use cases justify a replica. The first is reports, where long-running queries for asset, contract or ticket analysis can run against the replica so they do not hold locks or consume buffer pool memory that interactive users need. The second is search, where heavy read traffic from list and search pages can be routed away from the primary. The third is read-only fallback, where the replica remains available for lookups if the primary is down for maintenance or failing. The fallback case only works if someone has tested that GLPI can be pointed at the replica in a controlled way, and that the users and staff who depend on it understand that data may be behind the primary. Decide which of these three cases you actually need before you design the topology, because each one implies a different tolerance for lag.
A replica is not a backup and does not replace high availability design. Replication copies mistakes, accidental deletes and corrupted writes to the replica, usually within seconds, so you still need independent, tested backups of the database, the files directory and the GLPI key files. Failover, monitoring of replication health and promotion of a replica are separate decisions covered by your database architecture. MySQL and MariaDB both support asynchronous, semi-synchronous and parallel replication with global transaction IDs, according to the MariaDB/server README, and the MySQL Community Edition includes replication as well, but the choice among these modes and the failover design belong in your own plan. Confirm with your database team which replication mode and topology your platform standard supports before you commit.
Which GLPI workloads can move to a replica
Reports, dashboards and spreadsheet exports are usually the first candidates for a replica. They read large row sets and rarely write anything back. A monthly asset count or a ticket aging export can often tolerate a few seconds of lag, as long as the output shows when it was generated. The main risk is an expectation mismatch: a manager compares a report with what a technician sees on screen a moment later and finds the numbers differ.
- Reads: wide scans across tickets, assets, contracts and inventory tables, often with grouping and date filters.
- Writes: the report itself writes nothing, but export jobs may record status or notification entries that must stay on the primary.
- Staleness risk: a report run during a burst of ticket updates can omit the latest changes, which matters for SLA or audit evidence.
- Timestamps: the output should state its data source and generation time so a reviewer knows which view of the data they hold.
- Confirm: which report pages and export routines Teclib' documents as safe to direct at a replica.
Check that every report you route to the replica records its data source and run time before anyone relies on its totals.
Search results, ticket lists and asset grids make up much of the read traffic from technicians. They are good replica candidates by volume, but they are also the screens users judge by freshness. A ticket that was just assigned or closed and still appears in its old state can trigger a duplicate call to the service desk, so lag here is felt immediately.
- Reads: paginated queries with filters, sorting and joins across related item tables, with the session's entity and profile restrictions applied.
- Writes: list views do not write data, but saved searches and per-user display preferences are stored and must stay on the primary.
- Staleness risk: a newly created or updated item may be missing from results, or show its previous status, until the replica catches up.
- Access rules: entity and profile filtering runs inside the same query, so confirm the replica holds the same rights data as the primary.
- Confirm: whether Teclib' documents any routing for list and search endpoints, and how the interface behaves when the replica lags.
Test a create, update and immediate search sequence on a staging replica before enabling it for any list page the service desk uses.
A replica can keep read access available while the primary is patched, backed up or repaired. In this mode the application serves read-only pages and tells users that changes are unavailable. It is a continuity measure with its own operating rules, so it should be designed as an explicit state with a defined start and end, not left for users to discover during an outage.
- Reads: the same pages as normal operation, served from the replica for the length of the primary maintenance window.
- Writes: blocked or queued by design. Ticket creation, asset updates and login-related writes need defined behavior before the window opens.
- Staleness risk: the replica shows state as of its last applied transaction, so users need to know that cut-off time.
- Promotion: promoting a replica to primary is a separate operation with its own data loss and reconciliation questions.
- Confirm: whether GLPI documents a read-only mode, how sessions behave in it, and what Teclib' advises when the primary is unavailable.
Write the fallback runbook with a named owner, a message for users and a tested return-to-normal step before relying on it.
Anything that changes state must go to the primary. This includes ticket creation and updates, asset changes, session records, notifications, automatic action results and the queues that background tasks consume. The greater danger is subtle: a read that feeds a write decision can cause damage when it returns stale data, even though the write itself goes to the correct server.
- Ticket and asset changes: creates, updates, assignments and status transitions.
- Sessions and authentication: session and login state, which governs access decisions made on the next request.
- Background work: automatic actions, notification queues and log entries written by scheduled tasks.
- Decision reads: a permission check, SLA calculation or approval step that reads from the replica and then writes can act on old data.
- Plugins: third-party plugins may add tables or writes that the core documentation does not cover.
Before accepting any replica routing, confirm with Teclib' documentation which tables and code paths write data, and inventory each plugin in use along with its database access pattern.
Replica options and when each fits
This table compares the replication models named in the MariaDB and MySQL sources, covering how each one keeps replicas current, how failover behaves and where it fits a GLPI read workload. Read it as a starting point: the freshness and failover behavior you get depends on your configuration, and whether GLPI routes reads to a replica must be confirmed in the GLPI installation documentation for your version.
| Replication model | Data freshness | Failover behavior | Fit for GLPI |
|---|---|---|---|
| Asynchronous replication | Replica lags the primary by an amount that varies with write load and network conditions | Manual or scripted promotion; writes committed on the primary but not yet replicated can be lost | Good for reports and heavy searches where slightly old data is acceptable, and for a read-only fallback copy |
| Semi-synchronous replication | Primary waits for at least one replica to acknowledge receipt before confirming a commit, so the replica is usually closer to current | Promotion is still manual or scripted, but fewer committed transactions are at risk than with asynchronous replication | Suits reports that must reflect recent tickets and asset changes, if the added commit latency is acceptable for your write volume |
| Group Replication (MySQL) with automated failover | Members certify transactions through a group protocol, so replicas stay closely synchronized with the primary | Automated failover within the group, managed through MySQL Shell and MySQL Router in the Community Edition | Fits teams that want automated primary election in the database layer; confirm how GLPI connects through the router before relying on it |
| Galera synchronous multi-primary clustering (MariaDB) | Writes are synchronized across nodes before commit, so reads on any node reflect confirmed writes | Nodes can take writes, so failover is largely a matter of client connection routing; quorum loss must be planned for | Fits when the database itself must survive node loss with writes on any node; it adds operational complexity that a reporting replica alone does not need |
| Read-only fallback replica | Only as current as its last applied transaction, so stale results are possible during lag | Used to keep read pages available during primary outages; writes still need the primary | Confirm whether your GLPI version supports a read-only mode against a secondary database before designing around it |
| Routing reads to a replica through GLPI | Depends on the chosen replication model and lag monitoring in place | Depends on whether GLPI reconnects to a promoted primary without manual configuration change | Must be confirmed in the GLPI installation documentation for the installed version; do not assume routing support |
Setting up replication for GLPI step by step
This sequence adds a MySQL or MariaDB read replica to a running GLPI instance. When it is done, the replica holds a verified copy of the primary, GLPI sends read-only queries to it, and you have documented evidence of how far behind it runs.
Confirm GLPI and database versions
Record your exact GLPI version and the matching database requirements from the GLPI installation prerequisites page before you touch either server. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the GLPI 11.0 docs list MySQL 8.0 or MariaDB 10.6. Check both the primary and the replica against the version you run. Confirm that the replica engine matches the primary engine, because MySQL and MariaDB GTIDs are not interchangeable. Done means you have a written version matrix signed off by the database owner.
Prepare the primary with binary logs and GTIDs
The database administrator enables binary logging on the primary, assigns a unique server ID, and turns on global transaction identifiers. On MySQL this means setting gtid_mode and enforce_gtid_consistency; on MariaDB it means configuring the GTID domain settings for your topology. Create a dedicated replication account limited to replication privileges and restrict its host. Restart the primary during an agreed window. Check the result with a status query that shows binary logging is on and GTIDs are enabled, and confirm the server ID is unique across the pair.
Seed the replica from a consistent backup
Take a backup that captures a single consistent point in time on the primary. For InnoDB tables, a logical dump with a single-transaction option or a physical hot backup tool suited to your engine works, and the dump should record the binary log position or GTID set. Back up the GLPI files directory and the config directory, including glpi.key and glpicrypt.key, in the same change window, because the replica cannot run GLPI without them. Restore the database onto the replica and record the GTID set it contains. Done means the restore completed without errors and the recorded set matches the backup.
Start replication from the seeded point
On the replica, point the replication source at the primary using the replication account and enable GTID-based auto positioning, so the replica resumes from its own recorded transaction set. Start the replica threads. Then check the replication status output: both the I/O thread and the SQL thread should report running, the last error field should be empty, and the lag value should trend toward zero. If a thread stops, read the error text, fix the cause on the replica, and restart. Do not point GLPI at the replica until both threads stay running under normal write activity.
Point GLPI read traffic at the replica
Configure GLPI to send read-only work, such as reports and search, to the replica while writes stay on the primary. Confirm the exact configuration key and its supported behavior for your GLPI version in the GLPI database documentation before editing any file, and keep the change in your configuration management. Create a read-only database account on the replica for GLPI's read connection and grant it only the privileges GLPI needs for reads. Test one report, one search and one ticket creation. Done means reads come from the replica, the write lands on the primary, and no error appears in the GLPI logs.
Verify lag and data equality
Measure replication lag while GLPI runs its normal load, including scheduled tasks and inventory imports, and record the highest value you observe. Write a marker row through GLPI on the primary and confirm it appears on the replica within the lag you measured. For data equality, compare row counts and checksums on the tables your reports depend on, such as tickets, assets and computers, using a checksum tool that works across your engine. Document the results with timestamps. Done means you have a dated record of lag and matching checksums that your team can repeat after every change.
Document the stale-results rule for users
Decide which screens may show replica data and state the maximum lag your organization accepts for each. Ticket creation, approvals and any action that changes an asset stay on the primary, so a user never acts on an outdated record. Reports and search can show data that is seconds or minutes old, and the report header should say so. Write this decision into the operations runbook and tie it to the lag check from the previous step. Done means the runbook lists each read path, its accepted lag and the owner who approves changes to that rule.
How stale results happen and how to limit them
Asynchronous replicas apply changes after the primary commits them, so a ticket closed, an asset moved or an SLA field updated a few seconds earlier may still show its old value on the replica. Reports, search results and exports built from the replica can therefore disagree with the record a technician sees on the primary. The impact differs by use. An SLA report may list a ticket as breached after it was resolved, an inventory view may miss a laptop that an agent reported minutes ago, and an audit export may not match what the auditor sees in the live interface. Lag also grows during write bursts such as large agent inventory waves, bulk imports or a replication stall, so the gap is not constant and can be hardest to see when it matters most.
GLPI's replica handling includes options that decide whether a given read may be sent to a replica, based on how far the replica is behind the primary. The exact setting names, default behavior and what happens when a check fails depend on the version you run, so confirm them in the documentation for that release before you design around them. The trade-off is direct: a stricter check sends more reads to the primary and reduces the load you moved off it, while a looser check offloads more but accepts older data. Decide per use case. Dashboards and bulk reports usually tolerate some lag, while ticket detail pages, SLA calculations and audit evidence exports should read from the primary or be run only after you confirm the replica is current.
The replication mode on the database side sets the size of the window. MariaDB supports asynchronous replication by default, with semi-synchronous and parallel options and global transaction IDs that help you confirm replica position against the primary, as described in the MariaDB server README. Semi-synchronous replication narrows the window but does not remove it, so the GLPI setting remains the control that matters. Before go-live, measure replica lag under a realistic write load, set an alert threshold, and run a simple test: edit a ticket on the primary, then confirm the change appears in the report or search your users will rely on. Repeat the test after any replica restart or network interruption.
Security and operational risks of a replica
A replica adds a second database that holds copies of GLPI's data, credentials and schema, so it widens the attack surface and the operating workload. The cards below cover the access, transport, monitoring, backup and upgrade decisions that connect the replica to the rest of the GLPI platform. Each item is something to confirm in your own environment before the replica serves users.
Least-privilege replica accounts
Give the replica a dedicated read account that can only select from the tables reports and search need, and keep the write account off the replica entirely. Store its password in your secrets manager and rotate it on the same schedule as the primary. Confirm which GLPI configuration key or connection setting points at the replica and that the write path never uses it. A shared admin account on both servers is the most common shortcut to avoid.
Encrypted replication and client traffic
Replication traffic carries full row data, including user records and asset details, so it should run over TLS between the primary and replica. Ask your database team to confirm the TLS configuration supported by your MariaDB or MySQL version and to set client connections from GLPI to the replica to require encryption. Plaintext links across a data center boundary are a finding in most assessments.
Lag and broken replication alerts
A replica can stop applying changes while still answering queries, and GLPI will show stale data without any error. Alert on replication thread state, last error and seconds behind the source, and page the on-call owner when either replication thread stops. Pair these alerts with a check that compares a known record between primary and replica after maintenance windows. Confirm the alert thresholds with the team that will respond to them.
Backups that do not depend on the replica
A replica is not a backup. A bad delete or a corrupted table replicates to it within moments, so restores must come from backups of the primary, taken and tested on a separate schedule. Confirm that your backup tool captures the primary's binary logs for point-in-time recovery and that a restore has been rehearsed. Document who can run the restore and where backup copies are stored.
Schema changes during GLPI upgrades
GLPI upgrades run database updates with php bin/console db:update against the primary. The replica must receive those changes and must not be promoted or read by GLPI in the middle of an upgrade. Plan the order: pause reads from the replica, upgrade the primary, confirm replication has caught up, then resume. Check the release notes for the GLPI version you are moving to, since database requirements change between releases.
Encryption keys and config backups
The GLPI update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key. Encrypted values stored in the database cannot be read after a restore without the matching keys, so a database backup alone is incomplete. Store the key files with access controls separate from the database backup, and test that a restored instance can decrypt stored credentials. Confirm this with your own restore test.
Questions teams ask before adding a GLPI replica
What skills does a team need to add a MariaDB or MySQL replica to GLPI?
The team needs someone who can configure replication on the database engine, manage users and grants, and read replication status when something drifts. GLPI itself only supports MySQL and MariaDB, so the database work is standard server administration, but it is not a GLPI task. Application administrators who know GLPI's database settings still need a database engineer for the replication layer. Confirm before starting that the people who will own the replica can restore the primary, promote a server and explain how lag is measured in your chosen version.
How much does a GLPI read replica cost to run each month?
The main recurring costs are the second database server, its storage, backups, monitoring and the engineer time that keeps replication healthy. The one-time costs are design, build and testing against a copy of your data. Costs rise with database size, the number of reports that move to the replica, and how strict your recovery targets are. Ask any partner for a quote that separates one-time build work, hardware or cloud resources you pay directly, and ongoing monitoring, so you can compare it with the cost of simply tuning the primary.
Does a replica change how backups must be designed?
Yes. A replica is not a backup. A bad delete or a faulty schema change on the primary is copied to the replica within moments, so you still need point-in-time backups of the primary and tested restores. Backup design should also cover the replica's own configuration and the restore steps for rebuilding it from a fresh copy. Confirm that your backup tool can capture both servers consistently and that someone has performed a restore in a test environment.
What hardware does a second database server need for GLPI?
The second server needs enough memory, CPU and disk to hold the working set of the reporting and search queries you route to it, plus headroom for replication apply work. It does not need to match the primary exactly if it will serve only read-only fallback, but reports that run against it will feel any shortage. Size it by measuring query load on the primary first, not by guessing. Check the requirements for your GLPI release and the MariaDB or MySQL version you plan to run, since both change over time.
How does the size of the GLPI instance change the work?
A larger instance has more tables, more assets and more concurrent users, which means longer initial data synchronization, more replication traffic and slower verification runs. Heavy inventory ingestion on the primary also produces writes that the replica must apply continuously. A small instance with a few hundred users may need only a simple two-server layout, while a large one may need careful tuning of replication threads, monitoring of apply lag and a clear list of which pages use the replica. Ask for a sizing review that reads your current database growth and write rate before committing to a design.
How long does adding a GLPI replica take?
The duration depends on the size of the database, how many GLPI functions will use the replica, and how much verification you require. Initial copy time grows with data volume, and testing grows with the number of reports, search paths and fallback scenarios you need to prove. Confirm with any provider whether the timeline includes a rehearsal on a copy of your production data, a failover test and a monitoring setup, because those steps often take longer than the configuration itself. Ask for a written schedule that ties each phase to a deliverable.
What must our team provide before the replica work starts?
You need database administrator access to the primary and to the new server, along with the accounts that GLPI and your reporting tools use. Plan maintenance windows for the initial copy and for any cutover or failover test, and agree who approves them. A test copy of the production database is essential, since replication settings and GLPI routing should be verified there before anything runs in production. Provide the current GLPI version, the database version, the backup policy and a list of reports or dashboards that are expected to use the replica.
Can our internal team build and run the replica without a partner?
Yes, if you already have database engineers who run replication and a GLPI administrator who can change the database settings and test routing. The main gaps are usually replication monitoring, rehearsed failover and documentation of how GLPI decides when to read from the replica. A partner is most useful when the team lacks these skills, needs a fixed-scope build with written deliverables, or wants an independent test of the failover plan. Whichever route you choose, record the design so that the next upgrade does not depend on one person.
Do GLPI upgrades change how the replica is used?
They can. Each GLPI release may change the database schema, the minimum database version and the way the application uses the database. Before an upgrade, confirm that the replica runs a supported MariaDB or MySQL version for the target GLPI release, that replication still works after the schema update and that reports still return current results. Plugin updates need the same check, because a suspended or changed plugin may read different tables. Treat the replica as part of the upgrade test plan, not as an afterthought.
How DeployOpen scopes and delivers replica work
DeployOpen plans a GLPI replica as a fixed-scope engagement with the scope agreed in writing before any server is built. The first stage reviews the current database and workload: the MySQL or MariaDB version against the requirements for your GLPI release, table sizes and growth, which pages and reports generate the heaviest reads, how much of the load is search and dashboards, and where the primary's disk, memory and network already run close to their limits. The output is a list of candidate read paths and a clear statement of which ones are out of scope for the replica, so the team agreeing the work knows what will and will not change.
The second stage defines which features may read from the replica and which must always read from the primary. Reports, saved searches and exports are typical candidates for the replica, while anything that writes, checks a session, reads a just-changed record or drives an approval is usually kept on the primary. DeployOpen tests lag and stale-data scenarios against that list: a ticket updated on the primary and then viewed from a report, an asset imported by inventory and then searched, and what the user sees during a replication stall. The written runbook then records the lag threshold you accept, the sync check settings in use, the fallback behavior when the replica is unavailable, and who decides when to switch features back to the primary. Because GLPI upgrades change the database schema and the plugins that read it, DeployOpen also offers retainer support to retest the replica path against each new release and to keep the runbook current.
