Skip to content

Upgrading#

This documentation applies to Piler enterprise edition 2.2.5

Revision #4

Publication date: 2026-OCT-21

Upgrade steps#

Run the migrations#

Run mysql migrations on each piler related mysql database:

for i in /usr/share/piler/migrations/sql/*.sql; do
   mariadb --defaults-file=/etc/piler/.my.cnf piler < $i
done

Run manticore migrations for each tenant: In case of a multi-tenant deployment, be sure to use the tenant id

for i in /usr/share/piler/migrations/manticore/*.sql; do
   sed 's/TENANTID/piler/g' "$i" | mariadb -h0 -P9306
done

For a multi-tenant deployment, run the mysql migrations for all piler databases, also run the manticore migrations for all tenant ids as well, and replace "piler" in the sed command with the tenant id, eg.

sed 's/TENANTID/example001/g' ....

Add the participants column (2.2.5)#

Piler 2.2.5 adds the participants attribute to the index. piler, piler-ui, pilerimport and reindex check it at startup, and refuse to start until the column is there. The package upgrade stops the piler services, so back up the Manticore data, then run the script before starting them again:

/usr/libexec/piler/add-participants-column.sh 0 --all

The first argument is the Manticore host (0 is the local host). --all means the piler index and the index of every tenant in the tenant_settings table, so the same command works for single-tenant and multi-tenant deployments.

It's enough to run it once, but it's safe to run it again: it adds the column only to the indexes that don't have it yet, and leaves the others alone.

An index can't be searched while the column is added. Only the attribute files are rewritten, not the full-text index, but on a large index it may take a while, so do it in a maintenance window.

With Docker there's nothing to do: the piler-ee container runs the script at every start.

In a multinode setup upgrade the workers first, and run the script on every worker, not on the master: the tables of the master are distributed. Start piler-ui on the master only when all the workers have the column, otherwise it refuses to start.

Optionally fill the attribute of the messages archived before the upgrade:

reindex -tenantid piler -start 1 -stop <max metadata id> -participants -progress

It reads the addresses from the database, not the messages, can run while piler is archiving and users are searching, and can be interrupted and run again. Without it the messages archived before the upgrade are searched the same way as before.