Update to v26.04

Warning

In MITIGATOR v26.04, default settings for network interfaces have changed. For installations with more than four network ports, it may be necessary to increase the value of packet_mempool_size in data-plane.conf.
Read more.

Warning

Starting from MITIGATOR v26.04, Linux kernel version 5.0 or higher is required for TAP interface operation.

If you use traffic redirection to a TAP interface in the operating system, before updating MITIGATOR ensure that your OS uses the required kernel version, otherwise the TAP interface will not work.

Warning

Update to v26.04 must be performed from a minor version of v25.12.5 or later.

In version v26.04, the PostgreSQL version has been updated, so when updating MITIGATOR you need to delete the database and restore it from a full backup. A script for creating a full database backup is included in version v25.12.5+.

Preparation for Update

Update all MITIGATOR instances to version v25.12.5+ according to standard procedure.
After starting MITIGATOR on version v25.12.5+, wait for the message database system is ready to accept connections, press Ctrl+C.
Create a database backup on the MITIGATOR instance where the database is in Primary status:

Warning

To create a backup, execute the command below, which specifies backup_all.
Using the standard command from the Backup article will NOT transfer all necessary data.
```
docker-compose exec postgres sh -c 'backup_all > /tmp/backup_all.sql' 
docker cp $(docker-compose ps -q postgres):/tmp/backup_all.sql .
```
Verify that the backup was created without errors:
```
tail backup_all.sql
```
There should be no error messages in the output.
Stop all MITIGATOR instances (first with Standby database, then with Primary):
```
docker-compose down
```

Update to v26.04

On all instances, write the version line to the .env file:
```
VERSION=v26.04.X
```
Here X is the target minor version.

On all instances, download the current Compose file:

wget https://docs.mitigator.ru/master/dist/docker-compose.yml -O docker-compose.yml

On all instances, update the contents of docker-compose.failover.yml and docker-compose.worker.failover.yml files, if they are used.

Download the current files:
```
wget https://docs.mitigator.ru/master/dist/multi/docker-compose.failover.yml -O docker-compose.failover.yml && \
wget https://docs.mitigator.ru/master/dist/multi/docker-compose.worker.failover.yml -O docker-compose.worker.failover.yml
```
If the command: section of the pgfailover service was previously customized, for example to use more than two databases, then manually migrate these changes to the updated docker-compose.failover.yml and docker-compose.worker.failover.yml files:
- move the custom server list (formerly -server) to docker-compose.override.yml, overriding PGFAILOVER_SERVERS;
- if the number of connection attempts (formerly -attempts) was changed, set MITIGATOR_PGFAILOVER_ATTEMPTS in .env;
- if the server role check interval (formerly -interval) was changed, set MITIGATOR_PGFAILOVER_INTERVAL in .env.
Also transfer the values of the FWSTATS_GRAPHITE_ADDRESS and CARBONAPI_BACKENDS variables from the old files to the new ones.

Example of docker-compose.override.yml for three servers:
```
services:
  pgfailover:
    environment:
      PGFAILOVER_SERVERS: |
        postgres://repuser@${SERVER1}:5432/mitigator?sslmode=disable&connect_timeout=5
        postgres://repuser@${SERVER2}:5432/mitigator?sslmode=disable&connect_timeout=5
        postgres://repuser@${SERVER3}:5432/mitigator?sslmode=disable&connect_timeout=5
```
Info

docker-compose.override.yml is placed at the end of COMPOSE_FILE in the .env file: its settings must take precedence over settings from earlier files.

See the fault-tolerant storage setup for details.
On all instances, remove the MITIGATOR_OWN_INDEX variable from the .env file.
On all instances, download new images:
```
docker-compose pull
```
On the MITIGATOR instance where the database is in Primary status, delete the database:
```
docker volume rm mitigator_postgres
```
On the MITIGATOR instance where the database is in Primary status, start temporary Postgres container:
```
docker-compose run -d --rm --name postgres_idle postgres idle
```
On the MITIGATOR instance where the database is in Primary status, open Postgres logs:
```
docker logs -f postgres_idle
```
On the MITIGATOR instance where the database is in Primary status, wait for the message database system is ready to accept connections, press Ctrl+C. Ignore messages role "repuser" does not exist and role "backend" does not exist.

On the MITIGATOR instance where the database is in Primary status, copy the backup to the container and restore the data:

docker cp backup_all.sql postgres_idle:/tmp/ && \
docker exec postgres_idle sh -c 'psql mitigator </tmp/backup_all.sql >/tmp/restore.log'

Stop the temporary Postgres container and start the main service:

docker stop postgres_idle && \
docker-compose up -d postgres && \
docker-compose logs -f postgres

Wait for the message database system is ready to accept connections, press Ctrl+C.
On MITIGATOR instances where the database is in Standby status, delete the database:
```
docker volume rm mitigator_postgres
```
On MITIGATOR instances where the database is in Standby status, perform database initialization:
```
docker-compose run --rm -e PGPORT=15432 postgres standby
```
Start the MITIGATOR instance where the database is in Primary status:
```
docker-compose up -d
```
After startup, wait for all migrations to complete and settings to propagate.
Start other MITIGATOR instances:
```
docker-compose up -d
```