Keycloak 26.3.1 - Could excluding COMPONENT_CONFIG from database replication cause LDAP federation inconsistencies? #49875

DimaShaar · 2026-06-10T13:06:25Z

DimaShaar
Jun 10, 2026

Hello,

We are running the following environment:

Keycloak 26.3.1
MariaDB Active-Active replication
LDAP / Active Directory User Federation
Clustered Keycloak deployment

We recently observed an unexpected situation where a user who was previously working correctly appeared to have missing profile information and role assignments.

Additionally, we have seen cases where updates made to user attributes from Keycloak were stored in the Keycloak database but were not reflected in Active Directory.

Our database team informed us that the following tables are excluded from replication:

COMPONENT_CONFIG
OFFLINE_USER_SESSION
OFFLINE_CLIENT_SESSION
EVENT_ENTITY
ADMIN_EVENT_ENTITY

My main question is regarding COMPONENT_CONFIG.

Since this table contains federation and mapper configuration, could excluding it from database replication cause any of the following?

LDAP federation inconsistencies between nodes
Mapper configuration differences
User attribute synchronization issues
Missing user attributes
Missing role mappings or unexpected user visibility issues

Are there any documented recommendations, limitations, or known issues regarding Active-Active database replication and the replication of COMPONENT_CONFIG in Keycloak deployments?

Any guidance or similar experiences would be appreciated.

Thank you.

ruchikajha95 · 2026-07-24T09:20:45Z

ruchikajha95
Jul 24, 2026
Collaborator

Hi @DimaShaar ,

I hope you are doing well !

To answer your question directly: Yes, excluding COMPONENT_CONFIG from database replication is almost certainly the root cause of the issues you are seeing.

In a clustered Keycloak setup, Keycloak expects all active database nodes to hold a 100% identical and fully replicated schema.

Asynchro 8000 nous/partial replication (or selectively excluding tables) is not supported in Keycloak HA architectures.

About the specific table
The COMPONENT_CONFIG table stores settings for almost every pluggable component in a realm. Excluding it doesn't just break LDAP,it can also break RSA key providers, custom authentication flows, identity providers (OIDC/SAML), password hashing policies, and storage mappers. Missing this table is arguably one of the worst tables to exclude across nodes.

Attached Keycloak Multi-Cluster High Availability documentation, Keycloak requires a unified, fully synchronously replicated database (if this helps) .

Thanks

3 replies

dshaar1995 Jul 28, 2026

Hi @ruchikajha95 ,

I hope you are doing well.

Could you please clarify one point?

When we enable replication for the COMPONENT_CONFIG table (i.e., we no longer exclude it), we encounter the following replication error on both sides of the cross-data-center replication:

Last_Errno: 1032
Last_Error: Could not execute Delete_rows_v1 event on table moi_bc_keycloak.COMPONENT_CONFIG;
Can't find record in 'COMPONENT_CONFIG', Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND;
the event's master log mysql-bin.017738, end_log_pos 0

Have you encountered this type of replication issue before? If so, could you advise what might be causing it and how it should be handled in a supported Keycloak HA deployment?

Thank you.

ruchikajha95 Jul 28, 2026
Collaborator

Hi @DimaShaar,

I set up a local cluster lab to reproduce this exact scenario end-to-end (simulating an active-active setup, excluding COMPONENT_CONFIG, generating data drift, re-enabling replication, and fixing the resulting error).

Here is a breakdown of why you are seeing Error 1032 (HA_ERR_KEY_NOT_FOUND) and how to safely resolve it:

Why Error 1032 is Happening
Data Drift: While COMPONENT_CONFIG was excluded from replication, Node A and Node B maintained independent versions of that table. Any new mappers, updates, or deletions executed on Node A were never written to Node B.

When you re-enabled replication for COMPONENT_CONFIG, Node A sent a DELETE (or update) binary log event over to Node B for a record that Node A created while replication was off.

The Crash: Because Node B never received the initial INSERT statement for that record, it tried to delete a key that doesn't exist in its local database causing the replication SQL thread to fail with Error 1032.

Here is what i did :

To bring replication back online safely without losing configuration data, you need to bring the secondary database back in sync with your primary source of truth:

1.Stop the failing replication SQL thread on the secondary node.

2.Resynchronize COMPONENT_CONFIG from the primary database:
Dump the COMPONENT_CONFIG table from your primary node (the source of truth) and import it directly into the secondary node to align the primary keys and missing rows.

3.Skip the orphaned event and restart replication:
Since the table data on the secondary node is now identical to the primary node, advance the replication skip counter past the failing event and resume replication.

4.Verify replication health:
Check that both threads are running.

Once replication is restored, keep COMPONENT_CONFIG (and all other relational tables) 100% replicated synchronously across all nodes. As outlined in the Keycloak Multi-Cluster High Availability documentation, Keycloak relies on a unified, consistent database state to prevent split-brain cache states and synchronization issues.

Hope this helps your team get replication back in sync!

smitshah81 Jul 28, 2026

Hi @ruchikajha95 ,

We are running into a recurring MariaDB Error 1032 (HA_ERR_KEY_NOT_FOUND) across our Data Centers and would appreciate your guidance on how Keycloak handles or avoids concurrent updates to COMPONENT_CONFIG.

Our Scenario & Observed Behavior

Data Centers almost immediately hits Error 1032 on COMPONENT_CONFIG due to a concurrent Delete_rows_v1 event triggered on both sides.
Within the same single cluster, everything works without issues. The error only surfaces during cross-DC replication/sync.
3.Sometime Even when Keycloak is completely shut down / not running in DC2, replication still breaks on DC1. This happens because a DELETE statement previously executed or logged on DC2 gets replicated over to DC1, attempting to delete a record on DC1 that either no longer exists or was modified. ( is it possible that LDAP or any other part of keyclock is updating this table even keyclock serviec is down?)

We currently exclude transient/session tables from database replication to avoid similar conflicts :

OFFLINE_USER_SESSION
EVENT_ENTITY
ADMIN_EVENT_ENTITY
OFFLINE_CLIENT_SESSION

However, ignoring COMPONENT_CONFIG is not an option for us because excluding it breaks LDAP federation, user attribute mappers, and component configurations across sites.

Questions

Is there any configuration or mechanism in Keycloak to prevent Keycloak instances in DC2 from issuing concurrent COMPONENT_CONFIG updates/deletes at the exact same time when both DC are running?
Is COMPONENT_CONFIG expected to be updated automatically on node startup or cache invalidation, and if so, how can we serialize or delay these updates across multi-cluster deployments?
What is the recommended operational process when restoring/syncing a Keycloak DB snapshot to a secondary DC to prevent both sides from modifying COMPONENT_CONFIG simultaneously?

Any insights on preventing these simultaneous table updates during cross-DC sync would be greatly appreciated!

Thanks,
Smit

smitshah81 · 2026-07-30T10:23:45Z

smitshah81
Jul 30, 2026

Hi @ruchikajha95 ,

I had followed your instruction and restore whole kyeclock db to make sure on both node have same data. once we had started keyclock db on DC2 we had recived below error on same time.
On DC2

                Slave_IO_State: Waiting for master to send event
                   Master_Host: 10.8.51.135
                   Master_User: maxscale
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.017745
           Read_Master_Log_Pos: 69884349
                Relay_Log_File: node11-relay-bin.000019
                 Relay_Log_Pos: 5197449
         Relay_Master_Log_File: mysql-bin.017745
              Slave_IO_Running: Yes
             Slave_SQL_Running: No
               Replicate_Do_DB: 
           Replicate_Ignore_DB: 
            Replicate_Do_Table: 
        Replicate_Ignore_Table: 
       Replicate_Wild_Do_Table: 
   Replicate_Wild_Ignore_Table: 
                    Last_Errno: 1032
                    Last_Error: Could not execute Delete_rows_v1 event on table keycloak.COMPONENT_CONFIG; Can't find record in 'COMPONENT_CONFIG', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.017745, end_log_pos 0

On DC1

    
     Slave_IO_State: Waiting for master to send event
                   Master_Host: 10.8.151.135
                   Master_User: maxscale
                   Master_Port: 3306
                 Connect_Retry: 60
               Master_Log_File: mysql-bin.003419
           Read_Master_Log_Pos: 1065668691
                Relay_Log_File: node1-relay-bin.000014
                 Relay_Log_Pos: 406139397
         Relay_Master_Log_File: mysql-bin.003419
              Slave_IO_Running: Yes
             Slave_SQL_Running: No
               Replicate_Do_DB: 
           Replicate_Ignore_DB: 
            Replicate_Do_Table: 
        Replicate_Ignore_Table: 
       Replicate_Wild_Do_Table: 
   Replicate_Wild_Ignore_Table: 
                    Last_Errno: 1032
                    Last_Error: Could not execute Delete_rows_v1 event on table keycloak.COMPONENT_CONFIG; Can't find record in 'COMPONENT_CONFIG', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.003419, end_log_pos 0

Do we need to do this every time when config changes on any of the DC?
Kindly help us to solve this issue.

0 replies

Navigation Menu

Repository navigation

Keycloak 26.3.1 - Could excluding COMPONENT_CONFIG from database replication cause LDAP federation inconsistencies? #49875

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Keycloak 26.3.1 - Could excluding COMPONENT_CONFIG from database replication cause LDAP federation inconsistencies? #49875

Uh oh!

DimaShaar Jun 10, 2026

Replies: 2 comments · 3 replies

Uh oh!

Uh oh!

ruchikajha95 Jul 24, 2026 Collaborator

Uh oh!

dshaar1995 Jul 28, 2026

Uh oh!

ruchikajha95 Jul 28, 2026 Collaborator

Uh oh!

smitshah81 Jul 28, 2026

Our Scenario & Observed Behavior

Questions

Uh oh!

Uh oh!

smitshah81 Jul 30, 2026

DimaShaar
Jun 10, 2026

Replies: 2 comments 3 replies

ruchikajha95
Jul 24, 2026
Collaborator

ruchikajha95 Jul 28, 2026
Collaborator

smitshah81
Jul 30, 2026