DongHyeonkaandClaude Opus 5
df5af95cb3
Dropping the schema left Keycloak serving realm metadata and JWKS from its Infinispan cache, so the front door stayed at 200 while only the paths that read the database failed. That is a different shape from A-2, where the connection itself broke and readiness pulled the pods out of the Service; here the connection is fine and the tables are simply gone, which the health check does not notice. Restoring the pg_dump took one second with zero errors and no pod restart, and the row counts matched the backup exactly, sessions included. The real RPO is the backup interval plus the synchronous_commit loss measured in A-3, and this dump sits in the host's /tmp, which is the same failure domain as the thing it protects. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
18 lines
816 B
Plaintext
18 lines
816 B
Plaintext
=== ★ 파괴 — 스키마를 통째로 지운다 ===
|
|
시각: 14:59:47
|
|
DROP SCHEMA
|
|
CREATE SCHEMA
|
|
남은 테이블: 0
|
|
|
|
=== 서비스 영향 ===
|
|
https://auth.hyeonworks.com/realms/master HTTP 200
|
|
https://app1.hyeonworks.com/ HTTP 200
|
|
bff-555df79c97-6j86w 1/1 Running 0 49m
|
|
bff-555df79c97-vgg6g 1/1 Running 0 49m
|
|
keycloak-0 1/1 Running 0 4m15s
|
|
keycloak-1 1/1 Running 0 4m38s
|
|
|
|
=== Keycloak 이 무엇을 말하는가 ===
|
|
2026-09-04 05:58:02,598 WARN [org.keycloak.jgroups.protocol.KEYCLOAK_JDBC_PING2] (blocking-thread--p3-t2) Failed to fetch the cluster members from the database.: org.postgresql.ut
|
|
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2904)
|