Percona Toolkit on large GLPI databases

When Percona Toolkit is worth using on a large GLPI database

An online schema change tool fits when glpi_logs is large enough that a plain ALTER TABLE would hold a lock long enough to disrupt GLPI, and when the change is a schema or engine change you need to run on a live table. It does not shrink the table, reduce the amount of log data GLPI writes, or fix the growth itself, which is a retention question covered elsewhere on this page. Percona Toolkit's pt-online-schema-change is a common option for this kind of work on MySQL and MariaDB, the only database engines GLPI supports, but the exact behavior, flags and supported server versions must be confirmed against Percona's own documentation and tested on a copy of your server before you rely on it.

Before you choose the tool, confirm three things in your own environment. First, the server version and storage engine, since the tool's behavior depends on the database and table definition, and your GLPI release sets the minimum database version you can run. Second, whether glpi_logs has foreign keys, triggers or a reference from another table that the tool must handle, because these change how the copy and swap steps behave. Third, whether your GLPI instance can tolerate the write load and temporary disk use of a full table copy during business hours. Ask your database team to measure free space for the copy and to confirm how replication, if you run it, will see the changes. The GLPI installation prerequisites are the right reference for which database versions GLPI itself accepts.

Which glpi_logs changes suit an online change and which need a window

This table compares common glpi_logs changes against a maintenance-window approach, covering disk headroom, trigger overhead, constraint handling and rollback. Read each row as a question to answer on a restored copy before choosing a method, since the right choice depends on your MariaDB or MySQL version, table size and write volume.

Change	Online with pt-online-schema-change	Maintenance window
Engine migration (for example, to a different storage engine)	Copies all rows into a shadow table, so free disk must hold a full second copy plus indexes. Confirm the engine change is supported by the tool for your version.	Simpler to reason about and fewer moving parts, but writes stop for the full rebuild. Plan the window around the table size measured on your restored copy.
Column type change (for example, widening a field)	Trigger-based copy adds write overhead on every GLPI insert into the log table for the duration of the change. Confirm the new type maps cleanly from existing values.	Single rebuild with no triggers, so write overhead is zero during the change. Lock time grows with table size and must fit the agreed window.
Index addition	Builds the index on the shadow table while the application keeps writing. Measure extra disk and I/O on a restored copy before scheduling.	Index build locks or blocks writes for its full length on many setups. Often the easiest case to schedule in a window.
Index removal	Usually fast in metadata terms, but the tool still rebuilds the table, so disk headroom remains a concern. Verify query plans for GLPI reports after removal.	Fast to execute, but query regressions surface only after the window closes. Test affected GLPI pages and reports first.
Foreign key handling	Foreign keys referencing or referenced by the table need explicit handling. The tool may require flags or manual steps. Confirm behavior with your schema before running.	Foreign key checks can be disabled or handled in the window, which simplifies the change but risks data inconsistency if mishandled.
Unique constraint changes	Adding a unique key during copy can fail on duplicate rows that arrived mid-change. Check for duplicates on the restored copy first.	Duplicate detection happens before the change starts, so failure is easier to contain and retry.
Rollback	Requires a tested plan for dropping the shadow and trigger objects or restoring the original table. Confirm the tool's cleanup behavior for your version.	Rollback usually means restoring from a verified backup. Rehearse the restore time on a restored copy before the window.

Engine, column and index work on Percona Toolkit for GLPI

Moving a table to a different storage engine is the change with the widest blast radius. The tool rebuilds the table in the new engine through a shadow copy, so the engine itself must be available and fully supported on your exact MariaDB or MySQL release before anything runs. Confirm this against the vendor documentation for your build, not against the release you remember.

Engine availability: Check that the target engine exists on your server and is enabled in its configuration, and that your backup tooling can read tables stored in it.
Feature parity: Confirm that the engine supports the transaction, locking and foreign key behavior GLPI relies on during writes and automatic actions.
Replicas and clones: Verify that every replica, read endpoint and restore target can run the same engine, or replication will break silently.
Storage and footprint: Estimate disk space for the shadow copy and the old table, since both exist during the copy.
Rollback path: Decide in advance how you will restore the original engine, and test it on a copy.

Confirm all of these against the database vendor's current documentation and a staging copy of your own data before you schedule the change.

Index changes do not usually alter stored values, which makes them the lowest-risk category, but they still change how the optimizer plans queries and how long writes take. On a large glpi_logs table, an index added or dropped can change the plan for searches that GLPI runs from the interface and from automatic actions. Verify the effect with the queries your users and jobs actually issue.

Query inventory: Capture the slow queries and the search patterns from the logs and interface, then check which indexes they use today.
Duplicate or unused indexes: Confirm that an index you plan to drop is not needed by a foreign key or a plugin query.
Write cost: Expect inserts and updates to become slower with each extra index, and measure this on a copy under realistic load.
Uniqueness: A unique index fails if existing rows already contain duplicates, so check the data first.
Plan comparison: Record execution plans before and after, and keep them with the change record.

Ask your database vendor for the online schema change limitations that apply to your version, and confirm them on staging before the production window.

How to run an online schema change on glpi_logs safely

This sequence moves a large glpi_logs table through an online schema change with a verified backup, a rehearsal on a restored copy and a checked live run, so the GLPI log pages keep working throughout.

Confirm table size and disk headroom
The database administrator measures glpi_logs with information_schema, including data and index length, and checks free space on the data volume and the temporary space the tool will use for its shadow copy. Record the table size, the row count and the current engine and columns. Confirm with your DBA that free space comfortably exceeds the table size plus its indexes before continuing. If headroom is short, stop and reduce retention first using the controlling GLPI database growth with history purge topic.
Take and verify a full backup
Run a consistent dump of the GLPI database, then back up the files directory and the config directory, including glpi.key and glpicrypt.key. Follow the steps in the backing up and restoring a self-hosted GLPI topic. Restore the dump into a scratch database and confirm it loads and that row counts match the source. The step is complete only when a restore has been tested, not when the dump file exists. Stop if the test restore fails or any file is missing.
Rehearse the change on a restored copy
Restore the verified backup onto a non-production server with the same MariaDB or MySQL version and similar hardware. Run pt-online-schema-change with the --dry-run option to check the plan, then run it without that option against the copy. Record the duration, any errors and the triggers the tool creates. Check the resulting table definition with SHOW CREATE TABLE and confirm the GLPI log pages still load against the copy. Stop if the tool reports errors on triggers, foreign keys or unsupported column types.
Check replication and load during a dry run
If the production database has replicas, confirm replication lag is visible and watch it during the rehearsal, because the copied rows and the triggers generate extra writes on the replica. Monitor CPU, I/O and connection counts on the primary while the rehearsal runs, and compare them with normal business hours. Agree with the team on a pause condition, such as lag or connection saturation beyond a threshold they set. If lag grows or the tool throttles poorly, adjust the chunk and throttle options and repeat the rehearsal before any live run.
Run the live change in a planned window
Enable GLPI maintenance mode or schedule the change for a quiet period, then run pt-online-schema-change against the production glpi_logs table with the options validated in the rehearsal. Keep the terminal session open and watch progress and replication lag. The tool renames the new table and drops the old one at the end, so confirm the rename completed before leaving the window. Stop and let the tool clean up if errors appear, and do not drop the original table by hand until verification passes.
Verify row counts and the schema
Compare the row count and the maximum and minimum timestamps of glpi_logs with the values recorded before the change, then run SHOW CREATE TABLE to confirm the new engine, columns and indexes. Check that the helper triggers from the tool are gone. Confirm that replicas show the same table definition and row count. The step closes when the counts match and the definition matches the intended change. A mismatch is a stop condition: keep the original table and investigate before cleanup.
Verify GLPI log pages and application behavior
Sign in as an administrator, open the logs for several items and entity types, and run a search that spans the date range you use most often. Check that GLPI writes new log entries during a normal action such as editing a ticket, and that automatic actions that touch logs still run. Review the GLPI logs for database errors. Only after these checks pass should you remove the old table or the rehearsal copy, and record the change in your change log.

Risks of Percona Toolkit changes on a live GLPI database

Running pt-online-schema-change against glpi_logs changes a table that GLPI writes to constantly, so the risks are about load, disk, interrupted runs, dependencies, application behavior and rollback. Each card names what to verify before the change starts, and the checks overlap, so confirm them together in one change window.

Trigger overhead on a busy log table

pt-online-schema-change creates triggers on the source table that copy every insert, update and delete into the shadow table while the copy runs. On glpi_logs, where GLPI writes history entries during normal use and automatic actions, that doubles the write work for the length of the copy. Check write volume on the table over a typical week, pick a window with low activity, and set chunk size and throttle options with the DBA before starting. Confirm the trigger names do not collide with existing triggers on the table.

Disk space for the shadow copy

The tool builds a full copy of the table with the new definition before swapping it in, so free space must cover the new table, its indexes and the growth that happens during the copy. Also account for binary logs written by the copy and for the old table kept until you drop it. Measure the current size of glpi_logs with its indexes, confirm free space on the data volume and the binlog volume, and plan the drop of the old table as a separate, reviewed step.

Interrupted runs leave artifacts

If the process is killed, loses its database connection or hits a lock timeout, it can leave the shadow table and triggers behind, and the original table keeps running with those triggers attached. Before each run, list existing tables matching the shadow naming pattern and check the triggers on glpi_logs. Run inside a terminal multiplexer or a supervised job, keep the dry-run output, and write down the exact cleanup commands for a failed run before you start.

Foreign keys and replication

Foreign key constraints on or referencing the table can block or change how the tool behaves, and the tool has its own rules for tables with foreign keys. On a replicated MariaDB or MySQL setup, the trigger-based copy writes to replicas as well, so replica lag and binlog format matter. Confirm which constraints touch glpi_logs, check the replication topology and lag before and during the run, and tell the replica monitoring team when the change starts.

Queries and plugins that depend on the table

A changed column name, type or index can break GLPI queries that read history, and plugins that query glpi_logs directly may fail after the swap. Schema changes also interact with GLPI's own update path, so a later database update may expect the original definition. List the custom reports, plugins and scripts that reference glpi_logs, run them against a restored copy, and confirm the change is compatible with the GLPI version you run.

Rollback after the swap

Once the original table is dropped, reverting means restoring from backup, which can lose log entries written after the backup. Keeping the old table for a defined period preserves a fast reversal, but it doubles storage in the meantime. Decide before the change whether you will keep the original table, how long, and who signs off on the drop. Test the restore procedure on a copy of the database, and record the exact row counts and checksums before and after.

Why purging history first often reduces the risk

Shrinking the table before you change it is often the cheapest way to lower the risk of a large `glpi_logs` migration. A pt-online-schema-change run copies every row into a shadow table, keeps that copy in step through triggers, and then swaps the tables. The copy time, the disk needed for the shadow table and the amount of trigger work all scale with the number of rows and the size of the data on disk. If the history in glpi_logs is kept for longer than your audit or troubleshooting needs require, reducing retention with GLPI's own purge tooling may remove the need for a schema change at all. Before you commit to a migration, export the current row counts and table size, then compare them with the size you would reach after a purge. Confirm the retention periods your security and compliance owners require for log entries, since those periods decide how much history can go.

A purge is not free of risk. It permanently deletes log rows, so it needs its own backup and staged approach. Take a full database dump and confirm that it restores in a test environment before the first delete. Run the purge in stages, with a narrow date range or entry type at a time, and check the application, the audit trail you still need and the free space after each stage. Keep in mind that deleted rows do not return disk space to the operating system until the table is rebuilt or the storage is reclaimed, so the disk relief may arrive later than the row count suggests. The sibling topic on controlling GLPI database growth with history purge covers the retention settings, the PurgeLogs action and the reclaim steps in detail. Use it as the procedure for this step, and treat the purge as a change with its own approval, rollback plan and sign-off from the data owner.

What to confirm in your MariaDB or MySQL and GLPI versions

Before you run any online schema change on glpi_logs, confirm which GLPI release, database engine and replication topology you run. The version floors differ between the GLPI README and the installation docs, so the release you deploy decides which floor applies. Each card below is a check to complete with your own environment and the vendor documentation.

GLPI release and database floor

Start with the exact GLPI release you run, because the supported database versions depend on it. 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. The installation docs list different floors for GLPI 11.0, including MariaDB 10.6. Use the prerequisites page for your own release and record the figure you confirm before you choose a database version.

MariaDB or MySQL release and lifecycle

Record the exact server release, its support status and its end-of-life date. For MariaDB, confirm whether the release is LTS or rolling and whether it still receives security fixes. For MySQL, confirm whether the release belongs to the LTS or Innovation track, since Innovation releases are supported only until the next Innovation release. An online schema change adds load and disk use, so a server nearing end of life is a poor place to start the work.

Percona Toolkit version compatibility

Confirm the Percona Toolkit version you plan to use and check its documented database compatibility against your server release, including MariaDB where you run it. Pin the same version on every host that runs the tool, and test the exact command on a restored copy of the database first. Do not assume that a tool written for MySQL behaves the same way on every MariaDB branch without checking the release notes.

Foreign keys and plugin indexes on glpi_logs

Check whether glpi_logs has foreign keys, triggers or custom indexes added by plugins or local SQL changes. The tool creates a shadow table and rebuilds it, so foreign keys referencing or referenced by the table, and triggers attached to it, need explicit handling. Compare the table definition in your restored copy with the schema your GLPI release expects, and list every index a plugin added so you can recreate it after the change.

Replicas, Galera and replication topology

Determine whether the database uses asynchronous or semi-synchronous replicas, parallel replication, or a Galera cluster. Changes made on the primary can lag or conflict on replicas, and a Galera cluster handles writes differently from a single primary. Confirm how the tool's replication-aware options behave with your topology, and decide whether replicas should be rebuilt instead of altered in place.

Storage engine and backup readiness

Confirm that glpi_logs uses the storage engine your GLPI release expects and that you can take a verified backup before the change. Record free disk space on the data volume, because the copy needs room while the original table still exists. Note the backup location, the restore time from your last test, and who can roll back if the rebuilt table fails validation.

How to keep GLPI users and automatic actions safe during the change

Schedule the change for a window when few people create tickets or update assets, and keep the database work away from the inventory agents' check-in peaks. Before the window opens, list which GLPI automatic actions write to glpi_logs or other large tables, such as the log purge, mail collection, notification queue and inventory-related tasks, and decide with your GLPI administrators whether each one will be paused, left running or stopped for the duration. If you run them in CLI mode from cron, the schedule lives in the crontab and the automatic actions list in the GLPI administration console; record both so they can be restored exactly. Confirm each of these controls against your own change management and security policy, since the right window and the right actions depend on your user base and service levels.

Place GLPI in maintenance mode only where the change requires it, for example when a schema change would block writes that GLPI itself performs at login or while saving a ticket. Maintenance mode is controlled from bin/console, and the GLPI maintenance documentation describes how it affects users and automatic actions. Tell users in advance, and confirm with your security team whether maintenance mode changes what unauthenticated visitors see. Verify that the mode is off again and that a test login and ticket save succeed before you close the window.

Keep the database credentials used by the tool out of shell history and process lists. Pass them through a protected option file with restricted permissions, or through an environment variable set in the session, rather than typing a password on the command line where ps and shell history can expose it. Use a dedicated database account with only the privileges the change needs, remove the file or variable afterwards, and rotate the password if it was ever exposed. Check that your audit logging on the database server records who ran the tool and when, because the change itself will appear there as a set of writes. Confirm the exact method with your own security policy and database administrators before the first run.

What buyers ask about cost, effort and time for large GLPI table changes

What drives the effort of an online schema change on a large GLPI table?

Effort rises with the size of the table, the disk headroom available for the shadow copy, the write volume hitting the table during the change, the number of separate changes, and whether a realistic test environment exists. A table such as glpi_logs can hold far more rows than a typical GLPI table, so the copy phase and the replication lag checks dominate the work. Each change needs its own rehearsal, timing measurement and rollback plan. Ask your team to measure row count, table size on disk, and peak write rate before estimating anything.

Can our own team run pt-online-schema-change on GLPI without outside help?

Yes, if your database administrators are comfortable with MariaDB or MySQL replication, triggers, locking behavior and restore procedures. The tool is open source and the work is mostly planning, rehearsal and verification rather than tooling. Teams without a recent large-table change often underestimate the rehearsal and the monitoring needed during the run. A partner can take on the planning, the restored test copy, the runbook and the verification, while your staff keep ownership of production access and approvals.

What does the client need to provide for this work?

You need access to the database host and the GLPI application server in a non-production environment, a recent restored copy of the production database with comparable table sizes, and a change window in production that your operations team controls. You also need approval from the owners of GLPI and the database, a backup verified by a test restore, and monitoring access for replication lag, disk space and locks. Plan for named contacts who can stop the change if the metrics move outside the agreed limits.

How is a fixed-scope quote for this kind of work structured?

A fixed-scope quote usually separates the assessment, the rehearsal in a test environment, the production run and the post-change verification and handover. Each part has its own deliverables and acceptance points agreed in writing before work starts. One-time work covers the assessment, runbook and rehearsals, while ongoing support or follow-up checks may be offered as a retainer. Ask the quote to show who performs each step, what is excluded, and what happens if a rehearsal finds a blocker. DeployOpen does not publish a price list, so the quote follows from the written scope.

What should we ask for in a written scope before approving the change?

Ask the scope to name each table and each change, the MariaDB or MySQL version and storage engine in use, and the chunking and throttling settings to be tested. It should state the rehearsal dates in the test environment, the production change window, the rollback criteria, and the monitoring thresholds that stop the run. Require a list of excluded items, such as application upgrades or plugin changes, and a clear statement of who approves each step. Confirm the retention and cleanup of any shadow tables and the post-change verification checks.

Does the work require a maintenance window, and how long should we plan for?

Percona Toolkit is designed to avoid long table locks, but the change still consumes I/O, adds triggers and needs a window in which you can watch replication, backups and application behavior. The duration depends on the table size, the write rate and the throttling you accept, so no general figure applies. Ask the rehearsal results to set the window, and confirm with your change board whether the window overlaps scheduled backups, automatic actions or maintenance mode activity in GLPI.

What risks should the quote account for beyond the schema change itself?

The main risks are disk exhaustion from the shadow copy, replication lag on replicas, failed triggers during heavy writes, and an interrupted run that must be cleaned up. A bad backup or an untested rollback turns a small problem into an outage. Include the time for a restore test, the disk headroom check and a documented decision point. Ask the quote to state how any failed run is cleaned up and how GLPI behaves if writes to logs continue during the change.

How DeployOpen scopes and delivers large-table changes for GLPI

DeployOpen treats a large table change on a GLPI database as a planned workstream, not a single command. We scope the table, the change and the rollback path in writing, then build and rehearse the change against a copy of your data before anything touches production.

How we scope

Inventory the glpi_logs table size, growth rate, indexes and the GLPI version running against it.
Define the exact change: engine conversion, column type change or index work, with the reason for each.
Confirm the MariaDB or MySQL version, replication topology and maintenance window your team can accept.
Agree in writing which tables are in scope, what is excluded and who approves production execution.

How we build

Rehearse pt-online-schema-change on a restored copy of production data and measure lock and replication behavior.
Review trigger, foreign key and GLPI-specific side effects before choosing the alter strategy.
Script the run with dry-run output, throttling, chunk limits and a documented stop condition.
Prepare a rollback plan covering the shadow table, triggers and the original table until sign-off.

How we hand over

Deliver the runbook, command lines used, parameters chosen and observed timings from rehearsal.
Document post-change checks: row counts, GLPI web and console status, and the cleanup of leftover objects.
Record the backup taken before the change and the restore test result that supports it.
Walk your database and GLPI administrators through the procedure and the decisions behind it.

How we support

Support runs as a retainer for follow-up schema work, GLPI upgrades that affect these tables, and monitoring.
Re-check Percona Toolkit compatibility when you upgrade the database server or the Percona Toolkit release.
Plan the next retention or growth change so it does not repeat the same long-table problem.
Confirm support terms, response expectations and included hours in the written quote before work starts.

Using Percona Toolkit on large GLPI databases