Я пытаюсь кластеризовать мое приложение с некоторыми запланированными задачами на k8s с одним postgres db. Представьте себе следующую установку: 2x приложение, 1 дБ, на приложение 1 cronjob, например. обновить кеш.
Поскольку я не хочу использовать zookeeper или какую-либо другую реализацию, я пытаюсь использовать выборы руководства при весенней загрузке с таблицей на основе блокировок (INT_LOCK), как описано в весенних документах.
К сожалению, приложения запрашивают таблицу блокировки БД каждые пару мс, чтобы узнать, кто является лидером. Пока все хорошо, но приложение, НЕ удерживающее блокировку, пытается вставить новую запись, и, следовательно, БД генерирует нарушение ограничения Первичного ключа. Это продолжается и продолжается до тех пор, пока мой ПВХ не будет заполнен из-за записей в журнале ошибок моего postgres db ...
Эта процедура плохо документирована в Интернете. Я рад услышать любые ваши предложения;)
Пожалуйста, дайте мне знать, если мне нужно предоставить дополнительную информацию.
Заранее спасибо!
Класс конфигурации My Leadership:
@Configuration
public class LeadershipConfiguration {
private static final int LOCK_TIME_TO_LIVE = 120000;
private static final int LOCK_HEARTBEAT_TIME = 100000;
private static final int LOCK_ACQUIRE_WAIT_TIME = 110000;
@Value("${HOSTNAME:noname}")
private String podName;
@Value("${REGION:noregion}")
private String region;
@Bean
public DefaultLockRepository lockRepository(final DataSource dataSource) {
String clientId;
final DefaultLockRepository defaultLockRepository = new DefaultLockRepository(dataSource, this.podName);
defaultLockRepository.setRegion(this.region);
defaultLockRepository.setTimeToLive(LOCK_TIME_TO_LIVE);
return defaultLockRepository;
}
@Bean
public JdbcLockRegistry lockRegistry(final LockRepository lockRepository) {
return new JdbcLockRegistry(lockRepository);
}
@Bean
public LockRegistryLeaderInitiator leaderInitiator(final LockRegistry lockRegistry) {
final LockRegistryLeaderInitiator lockRegistryLeaderInitiator = new LockRegistryLeaderInitiator(lockRegistry, new DefaultCandidate());
lockRegistryLeaderInitiator.setHeartBeatMillis(LOCK_HEARTBEAT_TIME);
lockRegistryLeaderInitiator.setBusyWaitMillis(LOCK_ACQUIRE_WAIT_TIME);
return lockRegistryLeaderInitiator;
}
}
Я обновил конфигурацию LeadershipConfiguration, потому что согласно этому документу и этому документу это должно увеличить время между запросами, но, как кажется, это тоже не работает *
Также вот несколько операторов журнала из модулей:
Извлечение журнала БД, эти 3 сообщения журнала часто приходят:
2019-05-27 13:52:04 UTC
ERROR: duplicate key value violates unique constraint "pk_int_lock_lock_key"
2019-05-27 13:52:04 UTC
DETAIL: Key (lock_key, region)=(c444858e-0aae-3727-9a73-d2eae62321ad, DEFAULT) already exists.
2019-05-27 13:52:04 UTC
STATEMENT: INSERT INTO INT_LOCK (REGION, LOCK_KEY, CLIENT_ID, CREATED_DATE) VALUES ($1, $2, $3, $4)
etc... re-occuring statements
Извлечение журнала БД из модуля, который НЕ является лидером:
13:49:59.441 DEBUG o.s.jdbc.datasource.DataSourceUtils - Resetting isolation level of JDBC Connection [HikariProxyConnection@512836674 wrapping org.postgresql.jdbc.PgConnection@61ab89b0] to 2
13:49:59.444 DEBUG o.s.orm.jpa.JpaTransactionManager - Closing JPA EntityManager [SessionImpl(1800314718<open>)] after transaction
13:49:59.546 DEBUG o.s.orm.jpa.JpaTransactionManager - Creating new transaction with name [org.springframework.integration.jdbc.lock.DefaultLockRepository.acquire]: PROPAGATION_REQUIRED,ISOLATION_SERIALIZABLE,timeout_1
13:49:59.547 DEBUG o.s.orm.jpa.JpaTransactionManager - Opened new EntityManager [SessionImpl(1465858215<open>)] for JPA transaction
13:49:59.547 DEBUG o.h.e.t.internal.TransactionImpl - On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
13:49:59.549 DEBUG o.s.jdbc.datasource.DataSourceUtils - Changing isolation level of JDBC Connection [HikariProxyConnection@1224014205 wrapping org.postgresql.jdbc.PgConnection@61ab89b0] to 8
13:49:59.553 DEBUG o.h.e.t.internal.TransactionImpl - begin
13:49:59.553 DEBUG o.s.orm.jpa.JpaTransactionManager - Exposing JPA transaction as JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@5cd30775]
13:49:59.553 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL update
13:49:59.553 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL statement [DELETE FROM INT_LOCK WHERE REGION=? AND LOCK_KEY=? AND CREATED_DATE<?]
13:49:59.555 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL update
13:49:59.555 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL statement [UPDATE INT_LOCK SET CREATED_DATE=? WHERE REGION=? AND LOCK_KEY=? AND CLIENT_ID=?]
13:49:59.556 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL update
13:49:59.557 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL statement [INSERT INTO INT_LOCK (REGION, LOCK_KEY, CLIENT_ID, CREATED_DATE) VALUES (?, ?, ?, ?)]
13:49:59.559 DEBUG o.s.j.s.SQLErrorCodeSQLExceptionTranslator - Translating SQLException with SQL state '23505', error code '0', message [ERROR: duplicate key value violates unique constraint "pk_int_lock_lock_key"
Detail: Key (lock_key, region)=(c444858e-0aae-3727-9a73-d2eae62321ad, DEFAULT) already exists.]; SQL was [INSERT INTO INT_LOCK (REGION, LOCK_KEY, CLIENT_ID, CREATED_DATE) VALUES (?, ?, ?, ?)] for task [PreparedStatementCallback]
13:49:59.559 DEBUG o.s.orm.jpa.JpaTransactionManager - Initiating transaction commit
13:49:59.559 DEBUG o.s.orm.jpa.JpaTransactionManager - Committing JPA transaction on EntityManager [SessionImpl(1465858215<open>)]
13:49:59.561 DEBUG o.h.e.t.internal.TransactionImpl - committing
13:49:59.561 DEBUG o.s.jdbc.datasource.DataSourceUtils - Resetting isolation level of JDBC Connection [HikariProxyConnection@1224014205 wrapping org.postgresql.jdbc.PgConnection@61ab89b0] to 2
....
Извлечение журнала БД из модуля, являющегося лидером:
13:52:08.861 DEBUG o.s.i.s.l.LockRegistryLeaderInitiator - Acquiring the lock for LockContext{role=leader, id=ce77af6e-4bb0-459e-a83d-f33ef9192fd3, isLeader=true}
13:52:08.862 DEBUG o.s.orm.jpa.JpaTransactionManager - Creating new transaction with name [org.springframework.integration.jdbc.lock.DefaultLockRepository.acquire]: PROPAGATION_REQUIRED,ISOLATION_SERIALIZABLE,timeout_1
13:52:08.864 DEBUG o.s.orm.jpa.JpaTransactionManager - Opened new EntityManager [SessionImpl(1712215220<open>)] for JPA transaction
13:52:08.865 DEBUG o.h.e.t.internal.TransactionImpl - On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
13:52:08.865 DEBUG o.s.jdbc.datasource.DataSourceUtils - Changing isolation level of JDBC Connection [HikariProxyConnection@1507945608 wrapping org.postgresql.jdbc.PgConnection@7c72ecc] to 8
13:52:08.869 DEBUG o.h.e.t.internal.TransactionImpl - begin
13:52:08.869 DEBUG o.s.orm.jpa.JpaTransactionManager - Exposing JPA transaction as JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@7f1d0eae]
13:52:08.870 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL update
13:52:08.870 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL statement [DELETE FROM INT_LOCK WHERE REGION=? AND LOCK_KEY=? AND CREATED_DATE<?]
13:52:08.870 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL update
13:52:08.871 DEBUG o.s.jdbc.core.JdbcTemplate - Executing prepared SQL statement [UPDATE INT_LOCK SET CREATED_DATE=? WHERE REGION=? AND LOCK_KEY=? AND CLIENT_ID=?]
13:52:08.871 DEBUG o.s.orm.jpa.JpaTransactionManager - Initiating transaction commit
13:52:08.871 DEBUG o.s.orm.jpa.JpaTransactionManager - Committing JPA transaction on EntityManager [SessionImpl(1712215220<open>)]
13:52:08.872 DEBUG o.h.e.t.internal.TransactionImpl - committing
13:52:08.875 DEBUG o.s.jdbc.datasource.DataSourceUtils - Resetting isolation level of JDBC Connection [HikariProxyConnection@1507945608 wrapping org.postgresql.jdbc.PgConnection@7c72ecc] to 2
13:52:08.875 DEBUG o.s.orm.jpa.JpaTransactionManager - Closing JPA EntityManager [SessionImpl(1712215220<open>)] after transaction
13:52:09.376 DEBUG o.s.i.s.l.LockRegistryLeaderInitiator - Acquiring the lock for LockContext{role=leader, id=ce77af6e-4bb0-459e-a83d-f33ef9192fd3, isLeader=true}
....
Мой ожидаемый результат будет в том, что весенняя загрузка может справиться с этим изначально, и я могу некоторое время поддерживать и запускать свой пвх ... Эта проблема заставила мой пвх 1Gi заполниться в течение 3 дней ...