phacility/phabricator · critical · Exception

Multiple masters (databases "%s" and "%s") specify that they

Error message

Multiple masters (databases "%s" and "%s") specify that they are the "default" partition. Only one master may be the default.

What it means

In a partitioned multi-master cluster, the 'default' partition (the master serving any application not explicitly allocated) may be claimed by exactly one master. The parser throws this exception when a second master's partition list also contains 'default'.

Source

Thrown at src/infrastructure/cluster/PhabricatorDatabaseRefParser.php:103

          continue;
        }

        $server = $config[$key];
        $partition = idx($server, 'partition');
        if (!is_array($partition)) {
          throw new Exception(
            pht(
              'This server is configured with multiple master databases, '.
              'but master "%s" is missing a "partition" configuration key to '.
              'define application partitioning.',
              $ref->getRefKey()));
        }

        $application_map = array();
        foreach ($partition as $application) {
          if ($application === 'default') {
            if ($default_ref) {
              throw new Exception(
                pht(
                  'Multiple masters (databases "%s" and "%s") specify that '.
                  'they are the "default" partition. Only one master may be '.
                  'the default.',
                  $ref->getRefKey(),
                  $default_ref->getRefKey()));
            } else {
              $default_ref = $ref;
              $ref->setIsDefaultPartition(true);
            }
          } else if (isset($partition_map[$application])) {
            throw new Exception(
              pht(
                'Multiple masters (databases "%s" and "%s") specify that '.
                'they are the partition for application "%s". Each '.
                'application may be allocated to only one partition.',
                $partition_map[$application]->getRefKey(),
                $ref->getRefKey(),

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Remove 'default' from all but one master's 'partition' list.
  2. Give the other master only concrete application names (e.g. 'maniphest', 'diffusion').
  3. Re-validate the whole cluster.databases config after the edit (bin/config get + reload).

Example fix

// before
["partition" => ["default", "maniphest"]]  // db1
["partition" => ["default", "differential"]] // db2

// after
["partition" => ["default", "maniphest"]]  // db1
["partition" => ["differential"]]           // db2
Defensive patterns

Strategy: validation

Validate before calling

// Exactly one master may claim 'default'
$defaults = 0;
foreach ($cluster_database_config as $server) {
  if (!empty($server['master'])
      && in_array('default', idx($server, 'partition', array()), true)) {
    $defaults++;
  }
}
if ($defaults > 1) {
  // reject the config before deploy
}

Prevention

When it happens

Trigger: Two cluster.databases master entries both list 'default' in their 'partition' arrays; the parser hits the second claim while $default_ref is already set.

Common situations: Copy-pasting the first master's partition block to the second; splitting applications between masters and leaving 'default' on both sides 'to be safe'; merging config branches where each added its own default.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/aa8e03497a6d74c6. Report an issue: GitHub.