Comment se déplacez-vous sur PostgreSQL AutoVacuum en prenant un accès de verrouillage de la table exclusif sur les réplicas?
Nous courons:
user@primary/client-n:~$ psql -d database -c "SELECT version();"
version
---------------------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 10.7 (Ubuntu 10.7-1.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609, 64-bit
(1 row)
sur:
user@primary/client-n:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial
et avoir une configuration avec un client principal et deux clients de réplication en continu configurés avec:
user@client-n:~$ psql -d postgres -c "SELECT name, setting FROM pg_settings WHERE name IN ( 'hot_standby', 'hot_standby_feedback', 'max_standby_streaming_delay' );"
name | setting
----------------------------+---------
hot_standby | on
hot_standby_feedback | on
max_standby_streaming_delay | 150000
(3 rows)
Nous avons une base de données uniquement (autre que les normes) et une table dans la base de données. Environ 3 à 4 fois par jour, nous rencontrons une situation spéciale sur la documentation automatique décrite dans la documentation comme suit:
[...] il (Autovacuum) ne retournera pas l'espace au système d'exploitation, sauf dans le cas particulier où une ou plusieurs pages à la fin d'une table deviennent entièrement libres et une serrure de table exclusive peut être facilement obtenue.
Nous surveillons pg_locks et ont été capables d'observer le démon autovacuum en prenant le verrouillage de la table ACCESS EXCLUSIVE qui conduit à une foule de processus bloqués sur les clients illustrés par les entrées de journal ci-dessous:
Primaire:
...
2019-06-04 05:59:29.154 BST [8998-1] LOG: automatic vacuum of table "database.schema.table": index scans: 1
...
Client 1:
...
2019-06-04 05:59:03.660 BST [21167-858] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 21167 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.222 ms
2019-06-04 05:59:03.660 BST [21167-859] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 2741. Wait queue: 21167, 1215, 26415.
2019-06-04 05:59:03.660 BST [21167-860] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
2019-06-04 05:59:03.730 BST [1215-51] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 1215 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.188 ms at character 15
2019-06-04 05:59:03.730 BST [1215-52] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 2741. Wait queue: 21167, 1215, 26415.
2019-06-04 05:59:03.730 BST [1215-53] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
...
2019-06-04 05:59:19.975 BST [22242-4569] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 22242 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.281 ms at character 15
2019-06-04 05:59:19.975 BST [22242-4570] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 2741. Wait queue: 21167, 1215, 26415, 2423, 1289, 24009, 22441, 2640, 1843, 1056, 23336, 28060, 1860, 1134, 19419, 14649, 2721, 29540, 20138, 22242.
2019-06-04 05:59:19.975 BST [22242-4571] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT...
...
Et le processus tenant la serrure:
postgres=# SELECT pid, backend_type, wait_event_type, wait_event FROM pg_stat_activity WHERE pid = 2741;
pid | backend_type | wait_event_type | wait_event
------+--------------+-----------------+----------------
2741 | startup | Activity | RecoveryWalAll
(1 row)
Client 2:
...
2019-06-04 06:00:08.964 BST [16153-1] [PostgreSQL JDBC Driver@ip_address(port):role@database] | FATAL: terminating connection due to conflict with recovery
2019-06-04 06:00:08.964 BST [16153-2] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: User was holding a relation lock for too long.
2019-06-04 06:00:08.964 BST [16153-3] [PostgreSQL JDBC Driver@ip_address(port):role@database] | HINT: In a moment you should be able to reconnect to the database and repeat your command.
2019-06-04 06:00:09.964 BST [5747-537] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 5747 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.248 ms
2019-06-04 06:00:09.964 BST [5747-538] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 12709. Wait queue: 5747, 19765, 16036, 14617, 12280, 14513, 14728, 15398, 27611, 14542, 15948, 23398, 5853, 5098, 4324, 10760, 23480, 30192, 15300, 16228.
2019-06-04 06:00:09.964 BST [5747-539] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
2019-06-04 06:00:09.975 BST [19765-6847] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 19765 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.180 ms
2019-06-04 06:00:09.975 BST [19765-6848] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 12709. Wait queue: 5747, 19765, 16036, 14617, 12280, 14513, 14728, 15398, 27611, 14542, 15948, 23398, 5853, 5098, 4324, 10760, 23480, 30192, 15300, 16228.
2019-06-04 06:00:09.975 BST [19765-6849] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
...
2019-06-04 06:01:25.487 BST [15873-1] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 15873 still waiting for AccessShareLock on relation 16390 of database 16388 after 1000.218 ms at character 15
2019-06-04 06:01:25.487 BST [15873-2] [PostgreSQL JDBC Driver@ip_address(port):role@database] | DETAIL: Process holding the lock: 12709. Wait queue: 5747, 19765, 16036, 14617, 12280, 14513, 14728, 15398, 27611, 14542, 15948, 23398, 5853, 5098, 4324, 10760, 23480, 30192, 15300, 16228, 16127, 16285, 15873.
2019-06-04 06:01:25.487 BST [15873-3] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
...
2019-06-04 06:01:29.160 BST [16127-6] [PostgreSQL JDBC Driver@ip_address(port):role@database] | LOG: process 16127 acquired AccessShareLock on relation 16390 of database 16388 after 8560.748 ms at character 15
2019-06-04 06:01:29.160 BST [16127-7] [PostgreSQL JDBC Driver@ip_address(port):role@database] | STATEMENT: SELECT ...
...
Et le processus tenant la serrure, encore une fois:
postgres=# SELECT pid, backend_type, wait_event_type, wait_event FROM pg_stat_activity WHERE pid = 2741;
pid | backend_type | wait_event_type | wait_event
------+--------------+-----------------+----------------
12709 | startup | Activity | RecoveryWalAll
(1 row)
Les requêtes bloquées sur les clients entraînent une latence d'API comprise entre 10 et 20 secondes et occasionnellement, un nombre élevé de réponses 5xx. Out Sre Team a été chargé d'apporter la latence API lors de ces incidents et que nous recherchons des moyens de résoudre ce ce que nous comprenons comme une situation très niche. Nous expérimentons actuellement recovery_min_apply_delay = 120s sur le client 1 (d'où les entrées de journal ultérieures) afin que les deux clients ne se bloquent pas en même temps. Cela a quelque peu réduit son nombre de réponses erronées et abaissé un peu les pics de latence. Nous ne savons pas comment faire de la résolution de cette question pleinement et, en fait, s'il est possible de le faire. Nous apprécierions votre conseil. Nous avons trouvé ce poste connexe , mais malheureusement, cela n'a pas été résolu non plus.
Une manière non documentée d'éviter VACUUM troncature et le verrou exclusif requis est de définir old_snapshot_threshold à une valeur autre que -1. Cela se débarrassera à son tour des serrures et des conflits de récupération résultants.
De PostgreSQL V12 sur vous pouvez utiliser la meilleure technique de désactivation VACUUM troncature pour les tables individuelles:
ALTER TABLE mytab
SET (vacuum_truncate = on,
toast.vacuum_truncate = on);