Keeping Kong Functional During DB Down Times

When the database is down—due to maintenance or other reasons—Kong Gateway needs additional configuration to keep functioning without interruption.

During periods when the database is down—due to maintenance or other factors—you can configure several settings to minimize impact and keep the Gateway operational. Assuming you use the DB strategy, the only limitation is that vitals may not be written to the database during downtime.

Key configuration properties to manage cache behavior and provide resilience when the database is unavailable are:

• db_cache_ttl
• db_resurrect_ttl
• db_update_frequency

The db_cache_warmup_entities setting can be configured to prevent database access by warming up specific entities in the cache if they haven’t been used recently. By default, only services are warmed up by this setting — plugins are pre-warmed separately and are explicitly ignored by db_cache_warmup_entities. You can include other entities, such as:

• acls
• acme_storage
• basicauth_credentials
• ca_certificates
• certificates
• clustering_data_planes
• consumers
• hmacauth_credentials
• jwt_secrets
• keyauth_credentials
• oauth2_authorization_codes
• oauth2_credentials
• oauth2_tokens
• parameters
• ratelimiting_metrics
• rbac_roles
• rbac_users
• services
• sessions
• snis
• targets
• upstreams
• workspaces

Adjust mem_cache_size if warnings about cache size appear in the logs due to warming multiple entities.

Note: The routes entity does not require warming since it is cached in the in-memory router object. See the related pull request for reference.