Refactor database configuration in 00_database.php

[physikerwelt]

Removed conditional database configuration and added a reference to basic DB configuration in LocalSettings.php.

Fix #295

Summary by CodeRabbit

• Style
  • Minor formatting and comment capitalization tweaks in configuration files to improve readability; no behavioral or configuration changes.

[coderabbitai]

📝 Walkthrough

Walkthrough

Minor formatting-only edits in LocalSettings.d/base/00_database.php: a comment was capitalized and two blank lines were inserted before the next section marker. No functional or configuration logic changed.

Changes

Formatting & Whitespace Adjustment

Layer / File(s)	Summary
Comment change / Whitespace LocalSettings.d/base/00_database.php	Capitalized comment "Fall back to English otherwise" inserted after the LanguageCode check; two blank lines added before the "Basic DB configuration" section marker. No code logic altered.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

I nibble through code, light and spry,
A capital hop caught my eye.
Two blank beats, tidy and true,
The DB file breathes fresh and new. 🐇

🚥 Pre-merge checks | ✅ 2 | ❌ 3

❌ Failed checks (3 warnings)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title claims to 'refactor database configuration' but the actual changes are only minor comment formatting fixes with no configuration logic changes.	Update the title to accurately reflect the changes, such as 'Fix comment casing and remove stale commit-hash link in 00_database.php' to match the actual commit message and changeset.
Linked Issues check	⚠️ Warning	The PR does not address the core requirements from issue #295: raising 'max lag' value or switching to pt-heartbeat lag detection to fix false-positive DB lag detection.	Implement the proposed fix from issue #295 by adding 'max lag' => 3600 to the serverTemplate configuration in 00_database.php to prevent false-positive lag detection on Galera.
Out of Scope Changes check	⚠️ Warning	The PR contains only minor comment formatting adjustments that are unrelated to the linked issue #295 about fixing Galera lag detection.	Remove the out-of-scope formatting changes and focus on implementing the actual database configuration fix required by issue #295.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch remove-master-slave-config

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[physikerwelt]

@copilot check if that solves the linked issue and double check that the dbhost is set in production

[Copilot]

Pull request overview

This PR refactors MediaWiki database configuration by removing the conditional multi-server LBFactoryMulti configuration from LocalSettings.d/base/00_database.php and instead pointing to the “basic DB configuration” handled via LocalSettings.php (generated from LocalSettings.php.template). This aligns with the goal of avoiding the replica lag detection behavior described in issue #295.

Changes:

• Removed conditional LBFactoryMulti configuration that depended on DB_PRIMARY_IP / DB_SECONDARY_IP.
• Kept per-wiki $wgDBname selection logic and adjusted a comment (“English” capitalization).
• Added an in-file reference to where the base DB credentials are configured.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

LocalSettings.d/base/00_database.php (1)

31-35: ⚠️ Potential issue | 🔴 Critical | 🏗️ Heavy lift

Critical: Code changes do not address the stated PR objectives.

The PR description claims to have "Removed conditional database configuration" to address issue #295 regarding database lag detection and Varnish cache TTL. However, the actual changes shown are:

• Line 31: Capitalization of a comment (cosmetic only)
• Line 34: Addition of a reference comment pointing to LocalSettings.php

There are no functional changes to database configuration, no removal of conditional logic, and no changes related to 'max lag' settings or replication lag detection mentioned in issue #295.

The comment on line 34 suggests the actual database configuration changes are in LocalSettings.php, but that file is not included in this PR for review. This creates several problems:

1. Incomplete PR: If the actual fix is in LocalSettings.php, that file should be included in this PR
2. Misleading description: The PR title and description don't match the changes
3. Unverifiable fix: Without seeing the changes to LocalSettings.php, we cannot verify that issue #295 is actually addressed

Additionally, line 34 has a typo: "Localsettings.php" should be "LocalSettings.php" (capital S).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@LocalSettings.d/base/00_database.php` around lines 31 - 35, The PR claims to
remove conditional database configuration for replication lag detection but only
contains cosmetic comment changes; update the branch to include the actual
functional changes in LocalSettings.php (the DB config that sets replication max
lag / removes conditional logic used for lag detection and Varnish TTL), ensure
any conditional logic around $wgDBservers / replication/max lag is removed or
replaced with the intended always-on configuration in the same PR so reviewers
can verify fix, and fix the typo in the comment ("Localsettings.php" →
"LocalSettings.php") so the referenced filename matches the actual file;
reference the LocalSettings.php DB configuration block and any variables like
$wgDBservers, $wgDBserver, $wgDBadminuser, and max lag settings when making the
changes.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@LocalSettings.d/base/00_database.php`:
- Around line 31-35: The PR claims to remove conditional database configuration
for replication lag detection but only contains cosmetic comment changes; update
the branch to include the actual functional changes in LocalSettings.php (the DB
config that sets replication max lag / removes conditional logic used for lag
detection and Varnish TTL), ensure any conditional logic around $wgDBservers /
replication/max lag is removed or replaced with the intended always-on
configuration in the same PR so reviewers can verify fix, and fix the typo in
the comment ("Localsettings.php" → "LocalSettings.php") so the referenced
filename matches the actual file; reference the LocalSettings.php DB
configuration block and any variables like $wgDBservers, $wgDBserver,
$wgDBadminuser, and max lag settings when making the changes.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2f701a7b-9b2a-42f7-a6b8-a05ea3fd2374

📥 Commits

Reviewing files that changed from the base of the PR and between 7146f8b and 0d2f8f6.

📒 Files selected for processing (1)

• LocalSettings.d/base/00_database.php

[Copilot]

@copilot check if that solves the linked issue and double check that the dbhost is set in production

Yes, this solves the linked issue. The root cause was the LBFactoryMulti config (activated when DB_PRIMARY_IP and DB_SECONDARY_IP were set): it triggered SHOW SLAVE STATUS lag detection, which returns no rows on a Galera cluster, causing MediaWiki to treat every server as lagged and set X-Database-Lagged: true on every response, reducing the Varnish TTL to 30s. Removing LBFactoryMulti makes MediaWiki use a simple single-server setup with no replica lag detection, so the header is no longer set and Varnish uses the normal TTL.

Regarding dbhost in production: $wgDBserver is set from the DB_SERVER environment variable via LocalSettings.php.template (line 13: $wgDBserver = "${DB_SERVER}";), populated by envsubst in entrypoint.sh. DB_SERVER is also listed in REQUIRED_VARIABLES in entrypoint.sh, so it is always set in production.

[physikerwelt]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Done in 0b33f57. Fixed the comment on line 34: corrected filename casing to LocalSettings.php.template, removed the stale commit-hash link, and listed the specific variables set there ($wgDBserver, $wgDBname, $wgDBuser, $wgDBpassword).

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@LocalSettings.d/base/00_database.php`:
- Line 34: The comment incorrectly implies $wgDBname is only set in
LocalSettings.php.template; update the comment to state that basic DB
configuration variables ($wgDBserver, $wgDBname, $wgDBuser, $wgDBpassword) are
configured here and that $wgDBname is assigned/defaulted and may be overridden
conditionally within this file (refer to the $wgDBname assignments), so future
maintainers are not misled about the origin of $wgDBname.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0c30e915-14e0-4b01-bd43-4ebeb354dfb7

📥 Commits

Reviewing files that changed from the base of the PR and between 0d2f8f6 and 0b33f57.

📒 Files selected for processing (1)

• LocalSettings.d/base/00_database.php

[physikerwelt]

The database is currently overloaded, that is why this approach does not work

root@wikibase-8455d8558b-gp6lf:/var/www/html/w/extensions/MathSearch/maintenance# DB_SECONDARY_IP=false DB_SERVER=$DB_PRIMARY_IP php ProfilePages.php fixall --noJobs --loglevel debug

*******************************************************************************
NOTE: Do not run maintenance scripts directly, use maintenance/run.php instead!
      Running scripts directly has been deprecated in MediaWiki 1.40.
      It may not work for some (or any) scripts in the future.
*******************************************************************************

>>> Resuming from Page ID: 2330397
>>> Press Ctrl+C at any time to safely stop and save progress.
Wikimedia\Rdbms\DBConnectionError from line 111 of /var/www/html/w/includes/libs/Rdbms/LoadMonitor/LoadMonitor.php: Cannot access the database: Database servers in s1 are overloaded. In order to protect application servers, the circuit breaking to databases of th

[physikerwelt]

WMF does not use Galera, and some versions are broken. https://phabricator.wikimedia.org/T338070 documents that they would rather document incompatibily then fixing things. In addition, our ongoing performance problems may indicate that the Galera experiment has failed and we should consider using the well-established methods that WMF is using.