CRD Reference

Complete reference for Bloodraven custom resources (shipstream.io/v1alpha1).

CRDs at a glance

A category lists every kind in it: kubectl get bloodraven shows all five kinds in the namespace. The short names mbk and mbv are new in v1.7.0; mdb is not used, because other operators claim it. There is no backup category: kubectl expands a category before a resource name, so it would take over kubectl get backup and kubectl delete backup from other operators' backup resources (Velero, CloudNativePG), and a delete meant for those would delete Bloodraven backups and their artifacts.

MysqlFailoverGroup

Complete reference for the MysqlFailoverGroup custom resource (shipstream.io/v1alpha1).

Common fields quick reference

Spec

Names and fixed fields

The group's name is a DNS-1035 label (a lowercase letter first, then lowercase letters, digits or -, ending in a letter or digit), because it starts the group's Service names; a.b and 1orders are refused. The group's name plus each site's name is at most 41 characters, so the Dragonfly StatefulSet <group>-dragonfly-<site> fits in 52.

Some fields cannot change once set. Admission compares them by value, so the operator's own writes, which re-encode a timestamp in UTC or drop an explicit false, are not changes:

Top-level fields

Timers

Every timer in the spec is a duration string (30s, 5m, 1h) with a lower and an upper bound checked at admission (must be between <min> and <max>), so a zero or a value Go's time.Duration cannot hold is refused instead of being rewritten to a default. Integer ...Seconds fields remain only where the value is passed verbatim to a Kubernetes field (activeDeadlineSeconds, startingDeadlineSeconds, terminationGracePeriodSeconds, ttlSecondsAfterFinished) or compared with a MySQL or DNS value in seconds (maxLagSeconds, readOnlyMaxLagSeconds, maxLagSecondsForSource, dns.ttlSeconds).

Every string, list and map a validation rule reads has an upper bound, so each rule's estimated cost stays inside the API server's CEL budget on every supported Kubernetes version: timer strings are at most 64 characters, and the bounds of other such fields are given where they are described.

The CRDs store each default in Go's spelling (5m0s, 1h0m0s), the form the operator writes back, so a stored object does not change on the operator's first update. status.plannedFailover.settings holds the effective timers a run was accepted with; the operator writes it from these bounded inputs and it carries no bounds of its own.

SiteSpec

Each entry in spec.sites defines one site in the failover group.

Reader manifests may retain legacy loadBalancerIP and taintNodeSelector values for compatibility, but Bloodraven ignores them. Changing a reader to PrimaryCandidate or DisasterRecovery is rejected until both fields are present. A reader does not satisfy the two-candidate minimum and cannot appear in splitBrainPolicy.sitePriorities.

Admission combinations

StorageSpec

DNSSpec

TLSSpec

ReplicationSpec

SplitBrainPolicySpec

Opt-in configuration for how the operator should behave when more than one site is simultaneously writable and the operator cannot infer a winner from prior failover history. See Split-brain resolution for a full description of semantics and tradeoffs.

ServiceTemplate

SiteServiceTemplate (spec.sites[].serviceTemplate)

The operator preserves Kubernetes-assigned Service identity and compatible allocated NodePorts across reconciles and external-type transitions. Moving a site Service to ClusterIP clears external-only fields. The sidecar port is never exposed through a client Service or assigned a NodePort.

CredentialsSpec

credentials is required. The operator manages MySQL users on the primary — creating them during first boot via an init script and updating passwords via ALTER USER when the referenced Secrets change.

Secret references follow one convention across the five kinds: a field that names a whole Secret ends in SecretName and is a string; a field that selects one key of a Secret ends in SecretKeyRef and is a {name, key} object. Every Secret name is a DNS subdomain of at most 253 characters, and every key is at most 253 characters of [-._a-zA-Z0-9].

BackupSpec

Top-level backup configuration, embedded as spec.backup. Omitting the field disables backups for this failover group.

BackupProfile (spec.backup.profiles[])

PVC storage. pvc sets exactly one of claimName (an existing claim) and provisioned: {storageClassName?, size} (a claim the operator creates and owns, mysql-<group>-backup-<profile>; an unset class uses the cluster default, and a set one is a DNS-1123 subdomain). provisioned cannot change, be added or be removed while the profile stays in spec.backup.profiles, also not by switching storage.type to S3 and back. A backup whose owned claim has another class or a smaller request fails BackupStorageMismatch; see PVC backups. Renamed: pvc.storageClassName and pvc.size moved under pvc.provisioned, and the 10Gi default for an unset size is gone.

Bounds. s3.bucket is at most 63 characters, s3.region at most 64, s3.endpointURL and s3.prefix at most 512, pvc.claimName at most 253 and pvc.subPath at most 512. They are bounded in UTF-8 bytes as well as characters (CEL bytes(self).size()), at 63, 512, 512, 253 and 512 bytes, with messages such as "bucket must be at most 63 bytes (UTF-8)" and "prefix must be at most 512 bytes (UTF-8)". They keep the admission rule on the MysqlFailoverGroup root within the API server's CEL cost budget.

BackupEncryptionSpec

PassphraseSecretKeyRef

Reused by BackupEncryptionSpec, BackupDecryptionSpec, spec.initFromBackup.decryption, spec.restoreInPlace.decryption, and the MysqlStandbyCluster source.decryption; the bounds below apply to all of them.

For a backup profile, the operator snapshots the passphrase (see Key snapshots); a byte change on a profile whose PITR archive is in use is refused, and each backup's dumps use that backup's own dump-key snapshot.

BackupDecryptionSpec

Used on spec.initFromBackup.decryption and spec.restoreInPlace.decryption to supply the passphrase that decrypts an encrypted backup. When the source is a backupRef and the field is omitted, the operator uses the backup's own dump-key snapshot recorded in status.artifactStorage.passphraseSecretKeyRef; it never falls back to the profile's live Secret (PITRBackupDumpKeyMissing when neither exists).

BackupRetention

A successful MysqlBackup is kept when any rule keeps it: it is one of the newest keepLast, or it completed within keepWithinDays. It is deleted only when it is outside both. Failed CRs are counted separately. A backup that a verification may be reading is kept until the run stops. See Backup and restore → Retention, which also maps the released retention: N and retentionPolicy fields.

PITRSpec (spec.backup.pitr)

Enables continuous binary-log archival so restores can target an arbitrary stopTime on top of any retained full dump. See Backup and restore → Point-in-time recovery for the end-to-end story.

The archive under <prefix>/binlogs/ carries a write-once descriptor (archive.json) naming this group's UID, an archive ID derived from that UID and the normalized destination, and the encryption mode. Manifests are version 2 and name the archive ID. Writers need a store that enforces atomic create. Prefixes written before v1.7.0 are refused (ArchiveLegacy): use a new prefix and take a full backup. See Archive identity. The operator always owns replica-preserve-commit-order (ON, for every group, whether or not PITR is enabled). While PITR is enabled, replication or binlog filters, binlog_format other than ROW or binlog_row_image other than FULL in spec.mysqlConf are refused: they are left out of the rendered my.cnf and reported by the condition PITRMysqlConfAccepted=False / PITRUnsafeSettingRefused and a Warning PITRMysqlConfRefused. PITRArchiveReady=False / ArchiveUnsafeHistory comes only from a sidecar's history-integrity marker, that is, from a change made outside the spec.

Encryption change rule. A validation rule on the MysqlFailoverGroup root refuses an update that, with pitr.enabled true in both the old and new object and the same pitr.profileName, changes that profile's encryption (its presence, algorithm, passphraseSecretKeyRef.name or key) while its storage destination (type, bucket, prefix, endpoint, claim, sub-path) stays the same:

spec.backup.profiles[pitr.profileName].encryption (presence, algorithm, passphraseSecretKeyRef) cannot change while that profile archives PITR binlogs to the same storage; create a new profile with a new storage prefix and its own passphrase, switch spec.backup.pitr.profileName to it, wait until its archive binding is Bound, then take a full backup (see Backup encryption > Rotation)

An omitted algorithm equals AES-256-GCM and an omitted key equals passphrase. The rule compares references, so renaming the Secret to a copy with the same bytes is refused too. Edits with PITR disabled, across a pitr.profileName change, or together with a destination change pass admission and are judged by the group's archive encryption binding.

InitFromBackupSpec (spec.initFromBackup)

One-shot restore-on-first-boot. The operator runs a restore Job against the initial primary site before normal bootstrap is considered complete. Once status.restore.phase == Succeeded, subsequent reconciles skip the restore even if this field is still set.

The block is fixed at creation: admission refuses adding it to an existing group, removing it, or changing any field in it. A bootstrap that failed on a cause inside the block is retried by deleting the never-bootstrapped group and creating it again (see A failed bootstrap restore). Every string and list in it is bounded (a pvc source's claimName at most 253 characters and subPath at most 512, s3.region at most 64) so the rule stays within the CEL cost budget.

RestoreInPlaceSpec (spec.restoreInPlace)

Re-triggerable destructive restore against the currently-active primary. Unlike initFromBackup (one-shot, greenfield), this field is meant to be edited repeatedly: bumping confirm to a newer RFC 3339 timestamp re-arms another restore. See RestoreInPlaceSpec in the source for full semantics (full-instance vs. per-schema restores).

PointInTimeSpec (spec.initFromBackup.pointInTime)

Requests binlog replay on top of the loaded dump. Requires the source failover group to have had spec.backup.pitr.enabled=true at the time of the full dump — otherwise there is no archive to replay.

sites and allowUnverifiedCrossSite were removed in v1.7.0; replay considers every manifest in the archive. See Restore to a target timestamp.

Reconcile-time refusals set status.restore.reason and emit RestoreBuildFailed before any Job is created:

PITRBackupAfterTarget is not checked at reconcile: status.completionTime includes the upload and would refuse valid targets. dump-meta and the planner check the target against the dump's own end and the dumped server's clock. A logged load (loadOptions.skipBinlog: false) is also refused. The refusals dump-meta, pitr-download and restore.py can report are listed in Restore refusals.

PITR completion status (status.restore)

status.restoreInPlace.provenance has the same type; in-place restores have no pointInTime (see Point-in-time recovery is not supported in place), so its pointInTime stays unset. The flat sourceSizeBytes, sourceGtidExecuted, sourceBinlogFile, sourceBinlogPos, targetGtidExecuted, targetBinlogFile and targetBinlogPos fields and the top-level pointInTime are now under provenance. The flat pitrStopDatetime, pitrReplayedBinlogFile, pitrReplayedBinlogCount, pitrNewestEventTime, pitrPartial, pitrReplaySites and pitrCrossSiteUnverified fields of status.restore and status.restoreInPlace were removed in v1.7.0.

PointInTimeResult

One shape for MysqlFailoverGroup.status.restore.provenance.pointInTime, status.restoreInPlace.provenance.pointInTime and MysqlBackupVerification.status.pointInTime. It is filled only from a verdict the operator accepted (see How the operator reads the outcome).

PointInTimeVerificationSpec (MysqlBackupVerification.spec.pointInTime)

Also used by spec.backup.profiles[].verification.pointInTime for schedules. On a MysqlBackupVerification, failoverGroupRef, profileName, backupRef, pointInTime and sanityCheck are immutable (create a new verification instead); keepOnFailure, ttlSecondsAfterFinished and resources stay mutable. Its name is at most 63 characters, and sanityCheck.query at most 4096. Verification has no partial override. sites was removed in v1.7.0; verification reads every manifest in the selected PITR archive.

A Succeeded PITR verification records status.pointInTime (PointInTimeResult): lastReplayedBinlog.name is the last segment's file and newestReplayedCommitTime the newest replayed commit time. status.replayedThroughBinlog was removed; read those two fields instead. A latest-mode verdict that reports divergent transactions is refused PITRCoverageInvalid. A verification without pointInTime.archiveProfileName replays the group's own active archive, so it needs spec.backup.pitr.enabled (PITRTargetInvalid otherwise: "... so group <g> has no active PITR archive to replay; set pointInTime.archiveProfileName to the profile of the archive to replay (a retained archive needs no writer), enable spec.backup.pitr, or verify without pointInTime"); naming archiveProfileName replays a retained archive and needs no writer. When building its Job is refused with a PITR token (PITRTargetInvalid, PITRBackupIdentityUnknown, …), the token is the Verified condition's reason, not BuildJobFailed.

DragonflySpec (spec.dragonfly)

Optional cache/session sidekick management. Omitting this field or setting enabled: false preserves MySQL-only behavior and removes previously managed Dragonfly resources.

DragonflyAuthSpec

DragonflyPlannedFailoverSpec

DragonflySnapshotSpec

EncryptionAtRestSpec (spec.encryptionAtRest)

Requires spec.tls: MySQL mandates a secure connection to clone encrypted data and Bloodraven bootstraps every replica with CLONE INSTANCE. The CRD rejects enabled: true without it.

EncryptionCoverageSpec

Every field defaults to true. These are operator-owned once encryption is enabled: a spec.mysqlConf entry naming the same option is ignored, so a stray override cannot silently downgrade a site. Turning one off narrows the security claim.

KeyringSpec

mysqldDir and pluginDir are image-specific. The defaults match the official mysql:9.x images — MySQL only reads its global component manifest from the directory holding mysqld, and its global component config from plugin_dir, so a wrong value shows up as InnoDB refusing to start. The three directory fields must be absolute paths made of A-Z a-z 0-9 . _ / - (no trailing /), because the operator embeds them in the mysqld launcher script.

Full example

apiVersion: shipstream.io/v1alpha1
kind: MysqlFailoverGroup
metadata:
  name: orders
spec:
  image: mysql:9.7
  sites:
    - name: iad
      serverID: 101
      zone: us-east-1a
      taintNodeSelector:
        bloodraven.shipstream.io/failover-group.orders: "true"
        bloodraven.shipstream.io/site.orders: iad
      loadBalancerIP: 10.0.1.1
      storage:
        storageClassName: fast-ssd
        size: 100Gi
      resources:
        requests:
          cpu: "2"
          memory: "16Gi"
        limits:
          cpu: "4"
          memory: "16Gi"
    - name: pdx
      serverID: 102
      zone: us-west-2a
      taintNodeSelector:
        bloodraven.shipstream.io/failover-group.orders: "true"
        bloodraven.shipstream.io/site.orders: pdx
      loadBalancerIP: 10.0.2.1
      storage:
        storageClassName: fast-ssd
        size: 100Gi
      resources:
        requests:
          cpu: "2"
          memory: "16Gi"
        limits:
          cpu: "4"
          memory: "16Gi"
    - name: reader
      serverID: 103
      role: ReadOnly
      zone: us-east-1b
      mysqlConf:
        innodb_buffer_pool_size: "4G"
      serviceTemplate:
        type: LoadBalancer
        externalTrafficPolicy: Local
        nodePort: 32006
        annotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      storage:
        storageClassName: fast-ssd
        size: 100Gi
  credentials:
    operatorSecretName: mysql-operator-creds
  sidecar:
    resources:
      requests:
        cpu: "100m"
        memory: "64Mi"
      limits:
        cpu: "200m"
        memory: "128Mi"
  dns:
    hostname: orders.az.example.com
    ttlSeconds: 60
  tls:
    secretName: mysql-tls
  pollInterval: 2s
  failureThreshold: 3
  recoveryThreshold: 2
  failoverCooldown: 5m
  mysqlConf:
    innodb_buffer_pool_size: "8G"
    max_connections: "500"
    innodb_flush_log_at_trx_commit: "1"
    sync_binlog: "1"
  replication:
    maxLagSeconds: 300
    readOnlyMaxLagSeconds: 30
  updateStrategy:
    type: OrderedUpdate
  dragonfly:
    enabled: true
    image: docker.dragonflydb.io/dragonflydb/dragonfly:v1.38.0
    plannedFailover:
      maxSyncWait: 30s
      onSyncTimeout: Proceed
  cloneTimeout: 1h
  podLabels:
    cost-center: platform
  podAnnotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "9104"
  serviceTemplate:
    type: LoadBalancer
    externalTrafficPolicy: Local
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-internal: "true"
  extraContainers:
    - name: mysqld-exporter
      image: prom/mysqld-exporter:latest
      env:
        - name: DATA_SOURCE_NAME
          valueFrom:
            secretKeyRef:
              name: mysql-monitor-creds
              key: dsn
      ports:
        - containerPort: 9104

Full example (every credential role)

apiVersion: shipstream.io/v1alpha1
kind: MysqlFailoverGroup
metadata:
  name: orders
spec:
  image: mysql:9.7
  sites:
    - name: iad
      serverID: 101
      zone: us-east-1a
      taintNodeSelector:
        bloodraven.shipstream.io/failover-group.orders: "true"
        bloodraven.shipstream.io/site.orders: iad
      loadBalancerIP: 10.0.1.1
      storage:
        storageClassName: fast-ssd
        size: 100Gi
    - name: pdx
      serverID: 102
      zone: us-west-2a
      taintNodeSelector:
        bloodraven.shipstream.io/failover-group.orders: "true"
        bloodraven.shipstream.io/site.orders: pdx
      loadBalancerIP: 10.0.2.1
      storage:
        storageClassName: fast-ssd
        size: 100Gi
  credentials:
    operatorSecretName: mysql-operator-creds
    appSecretName: mysql-app-creds
    monitorSecretName: mysql-monitor-creds
    backupSecretName: mysql-backup-creds
  dns:
    hostname: orders.az.example.com
    ttlSeconds: 60

Each referenced Secret must contain username and password keys. The operator secret additionally requires MYSQL_ROOT_PASSWORD:

apiVersion: v1
kind: Secret
metadata:
  name: mysql-operator-creds
stringData:
  username: bloodraven
  password: <operator-password>
  MYSQL_ROOT_PASSWORD: <root-password>
---
apiVersion: v1
kind: Secret
metadata:
  name: mysql-app-creds
stringData:
  username: app
  password: <app-password>

Status

The operator writes the following status fields.

Top-level status

PITRArchiveObservation

status.pitr.archive is written by the topology runner from the sidecars' /archiver/statusarchive blocks. Only reports for the group's active PITR destination count: a pod still on an older render reports another destination, or none.

See Archive identity for what each reason means.

PITRArchiveBinding

status.pitrArchiveBindings[]. See Archive encryption bindings. Encrypted bindings that were accepted are rebuilt from their key snapshot after a status loss; plaintext bindings are proven again.

SiteStatus

PlannedFailoverStatus

Every field belongs to the run named by runID. The operator writes the block with a status update conditioned on the object's resourceVersion, one write per transition, and refuses a non-terminal block without a runID (a block an older operator wrote). The CRD schema marks no field of the block required (an older operator rolled back onto this CRD must still be able to write its own block); the fields described as "always set by the operator" are set on every block this operator writes, and their minimum length or value still applies when present. See Planned failover for the lifecycle.

Removed in this release (an older operator wrote them): target (now targetSite), sourcePrimary (now sourceSite), sourceGtidAtFence (now fence.gtidSet), targetGtidAtPromotion (dropped: the gate proves the target held exactly the fenced set), completionTime and reason (now under result), durationSeconds (derive it from startTime and result.completionTime; the duration histogram is unchanged), transactionsLost (dropped: always 0 by construction), maxLagWait and drainTimeout (now under settings), drainStartTime (now drain.startTime), lagWaitStartTime (now lagWait.startTime), retryAfter (now admission.retryTime), the phases Pending, Validating and Resuming, and the Dragonfly fields enabled, sourceOffsetAtDrain, offsetCaptureFailed, targetOffsetAtPromotion, sessionsPreserved (now sessions) and promotionMethod (now takeover.method).

Conditions

The topology conditions (Ready, Degraded, Bootstrapping, Updating, RecoveryPending, DivergentPromotion) carry the generation the topology manager applied, the same value as status.observedGeneration, so a spec edit the manager has not taken up yet does not read as observed. A condition another writer owns (S3CredentialsReady, PITRMysqlConfAccepted, PITRArchiveReady, PITRArchiveBindingReady, the encryption conditions) carries the generation that writer evaluated.

EncryptionAtRestStatus

SiteEncryptionStatus

SiteEncryptionCoverage

Sampled from the live instance, not inferred from my.cnf. A site can be Sealed and still have incomplete coverage -- for example an adopted cluster whose pre-existing tables were never rebuilt. Every boolean flag is optional: it is absent when the probe did not report it, and an unknown value is never reported as false.

DragonflyStatus

DragonflySiteStatus

Annotations

Well-known metadata is the complete list of the labels, annotations, finalizers and the taint Bloodraven reads or writes, with each key's writer, value grammar and stability level. Action annotations share one value grammar, <subject>(:<key>=<value>)*; a destructive action on a site carries confirm=<metadata.name>:uid=<metadata.uid>, where the uid is kubectl get mfg <group> -o jsonpath='{.metadata.uid}', so a request left over for an earlier group of the same name does not apply.

PITR archive binding metadata

Labels and annotations the operator puts on objects it creates for archive encryption bindings. They are internal unless marked otherwise: select on them for listing, but do not set or edit them.

Example status

status:
  observedGeneration: 4
  activeSite: iad
  sites:
    - name: iad
      state: Writable
      lastSeenTime: "2025-01-01T00:00:00Z"
      replication: NotApplicable
    - name: pdx
      state: ReadOnly
      lastSeenTime: "2025-01-01T00:00:00Z"
      replication: Healthy
      secondsBehindSource: 0
      gtidExecuted: "uuid:1-100"
      sourceHost: mysql-orders-iad-internal.orders.svc.cluster.local
      sourceConvergenceState: Converged
      sourceConvergenceReason: DirectSource
    - name: reader
      state: ReadOnly
      lastSeenTime: "2025-01-01T00:00:00Z"
      replication: Healthy
      secondsBehindSource: 0
      gtidExecuted: "uuid:1-100"
      sourceHost: mysql-orders-iad-internal.orders.svc.cluster.local
      sourceConvergenceState: Converged
      sourceConvergenceReason: DirectSource
  conditions:
    - type: Ready
      status: "True"
      reason: Healthy
      observedGeneration: 4
    - type: Degraded
      status: "False"
      reason: Healthy
      observedGeneration: 4
  lastFailover:
    time: "2025-01-01T00:00:00Z"
    target: iad
    promotionGtidExecuted: "uuid:1-90"
  dragonfly:
    activeSite: iad
    phase: Ready
    message: all sites ready
    sites:
      - name: iad
        role: Master
        reachable: true
        ready: true
      - name: pdx
        role: Replica
        reachable: true
        linkStatus: up
        ready: true

MysqlBackup

One backup run. Created by hand or by a schedule CronJob. See Backup and restore. The spec names the failover group (spec.failoverGroupRef.name), the profile (spec.profileName, a DNS label of at most 63 characters) and optionally spec.sourceSite, a site of that group to take the dump from. spec.deletionPolicy (Delete by default, or Retain) decides what deleting the CR, by hand or by retention, does to the artifact: Delete removes the artifact from storage and then the backup's dump-key snapshot Secret; Retain runs no cleanup, keeps both, and records a Normal ArtifactRetained Event naming them (delete them by hand when no longer needed). Retain does not keep the storage itself: a claim the group provisioned (pvc.provisioned) is deleted with the group, with every artifact on it (see Deleting a group without losing backups). It is read when the deletion is processed. A backup re-created with the name of a retained one fails at its backup stamp step while the retained dump is still at that location. failoverGroupRef.name is a DNS subdomain of at most 253 characters, and spec.sourceSite a site name (a DNS label of at most 20 characters). failoverGroupRef, profileName and sourceSite are immutable: to back up something else, create a new MysqlBackup. deletionPolicy stays mutable. The backup's own name is at most 63 characters (it is a label value on the objects the run creates). A name ending in .bloodraven-backup.json is refused at admission: that suffix is the backup stamp object's.

Status

kubectl get mysqlbackup shows Group, Profile, Phase, Ready (the Ready condition's status), Started, Completed and Age; -o wide adds the Location (.status.artifactStorage.location) and Size columns.

Reasons from archive encryption bindings: Pending with PITRArchiveRolloutPending (a backup of the active PITR profile while the sites render different archive IDs), PassphraseSecretMissing (the encrypted profile's Secret or key is missing, so no dump-key snapshot can be made) or DumpKeySnapshotConflict (the dump-key snapshot name is held by another backup's Secret); Failed with ProfileReadOnly (the profile is read-only).

ArtifactStorage (status.artifactStorage)

Recorded from the producing Job when it is created, or recovered from that Job for backups taken by older operators. Restores, verifications, PITR dump metadata and cleanup read the bucket, endpoint, region and claim from here and never follow later edits of the profile's bucket, endpoint, prefix, subPath or claim. A PVC backup therefore needs no profile to be restored or verified.

Credentials are deliberately not part of it: restores, verifications and cleanup read them from the profile's current credentialsSecretName, so rotating keys needs no change on old backups. Cleanup also deletes the backup stamp, <location>.bloodraven-backup.json; see Backup stamp.

Once artifactStorage.location is recorded, a validation rule on the MysqlBackup resource rejects any update that changes or removes status.artifactStorage, including removing or nulling the whole status through the status subresource. The rule is evaluated on the resource root, so it cannot be bypassed by dropping the parent object first.

Conditions

Annotations

MysqlStandbyCluster

Phase 1 of WISHLIST #7. A passive DR relationship descriptor that lives on the DR cluster and continuously monitors a source MysqlFailoverGroup's dumps and PITR archive in a shared object store. The controller populates status.discovered and stamps readiness conditions on a configurable cadence. No mysqld is started, no dump is loaded and nothing is written to the bucket.

See Multi-cluster DR for the end-to-end recovery runbook and a full explanation of what the standby does and does not provide.

Top-level spec fields

StandbySource

The standby identifies its source by the prefix alone. The archive descriptor under <prefix>/binlogs/ names the source group (namespace, name and UID), and the standby publishes it in status.discovered.binlogArchive.identity. Use metadata labels for a display name.

StandbyS3Source

The S3 fields of a backup profile's storage.s3 that apply to a reader, with prefix required. The bounds are the profile's (see BackupProfile).

StandbyFreshnessSpec

Restore verification and activation are not implemented, so the API has no fields for them: no verification cadence or staleness knobs, no activation request and no template of the group an activation would create. Unknown fields have no effect: the API server prunes them (they are silently dropped and never persisted), and clients using strict server-side field validation — the default for kubectl apply/create since Kubernetes 1.25 — reject them outright.

Status

status.discovered:

kubectl get msc shows Dump (the latest dump's name), NewestBinlog (the newest archived event time), Ready (the Ready condition's status) and Age.

Conditions