Databases

Hibernator stops your RDS instances together with the workloads, and starts them again before the workloads need them. Every key named here is under config.databases.

A managed database stops once no up reason has held for the stop delay. It starts one earlyStart before the next working-hours boundary. The config.databases section is empty by default, and the feature is off while the section is empty. enabled: false is a kill switch that keeps the entry list.

Give the controller the RDS permissions in aws-integration.md before you add an entry.

Note

The controller runs the full stop and start cycle and adds the databases to the wake barrier. The stopped hours count in the savings figures and in the Sustainability estimate. RDS starts a stopped instance by itself after 7 days: Hibernator stops it again and reports State Mismatch Detected. The Resources page lists every entry with the start and the stop that are due next.

• When a database is up
• Instances that Hibernator did not stop
• Configuration
• Validation
• Awake windows

When a database is up

An instance must be available while at least one up reason holds:

• The cluster is effectively up: working hours with no manual hibernation held through them, an active wake, or any inbound external wake session, whatever its resource list.
• One of the awake windows of the entry is running.

Every reconcile works this out again from the start. No phase is stored, so a restart in the middle of a cycle needs no recovery.

Start: Hibernator starts the instance one earlyStart (default 15m) before the next up reason begins. A scheduled wake then usually finds the instance up and passes the barrier at once. A manual wake or an inbound external wake session comes without notice. It waits for the 8-9 minute instance start inside the barrier.

Stop: Hibernator stops the instance only when all three conditions are true:

• No up reason has held for stopDelay (default 30m).
• The scale-down of the applications is finished.
• The stop would be longer than minimumStopDuration (default 60m).

The stop delay covers the KEDA and HPA drift. An HPA can scale a deployment up again for up to one reconcile interval after the hibernate transition reports complete.

The minimum stop duration limits the stop, not the gap. No instance stays down until the next up reason, because the early start brings it back one earlyStart before. So the guard compares gap - earlyStart, and the defaults need a 76-minute gap, not a 61-minute one. This measure counts too little on purpose. RDS bills instance hours only from available, so the 8-9 minutes that the instance spends starting are not billed. If the guard is wrong, it is better wrong in this direction.

Instances that Hibernator did not stop

Hibernator stops only an instance it finds available, and starts only one it stopped itself. An instance that a DBA stopped stays stopped. Hibernator records its claim in the database_states key of the hibernator-state ConfigMap: one small record per entry, keyed by name.

The rule applies to both start paths: the early start of the schedule, and the wake barrier when it releases a tier. A wake during a maintenance stop thus leaves the instance alone, and the tier waits until its timeout.

When you remove an entry from the configuration, its record stays. If you add the entry again, Hibernator can still start the instance.

A status that Hibernator cannot read decides nothing in that pass. The instance stays as it is, and the next pass reads it again.

Records that Hibernator cannot read are the one exception, and only in the barrier. The reconcile then leaves every database alone. A released tier starts every instance it finds stopped. A wake that does not bring the environment up is worse than one start too many.

A hibernator-state ConfigMap that does not exist yet is an empty read, not a failure. A new installation thus starts nothing that it did not stop. If the records are lost while instances are stopped, the instances stay stopped. The Wake Barrier Timeout notification names each one with status stopped until you start it.

With config.operations.dryRun: true, Hibernator logs the decision and makes no RDS call. The state record still tracks the observed status and the down clock. The preview thus reaches the point where it would report a stop, and does not reset on every pass.

Configuration

config:
  databases:
    enabled: true
    defaults:                             # inherited by every entry
      earlyStart: "15m"
      stopDelay: "30m"
      minimumStopDuration: "60m"
    entries:
      - name: "orders-db"                 # stable handle for UI, state and savings - not the identifier
        kind: "rds-instance"              # the only kind
        wakePriority: 100                 # >= 1, same number space as the tier list
        earlyStart: "20m"                 # optional per-entry overrides of the three durations
        awakeWindows:                     # optional: available regardless of working hours
          timezone: "UTC"                 # default: config.workingHours.timezone
          windows:
            - days: [monday, tuesday, wednesday, thursday, friday]  # default: every day
              start: "01:00"              # HH:MM
              end: "01:45"                # HH:MM, or "24:00" for midnight at the close of the day
                                          # an end before the start spans midnight: "23:25"-"00:10"
              reason: "nightly batch job"
        rdsInstance:                      # block named as the camelCase of kind
          identifier: "orders-db-01"
          region: "eu-central-1"          # default: the controller's own region

wakePriority puts the database in a wake tier. wake-order.md says which tier to use.

Validation

A bad entry fails the whole configuration. Hibernator does not skip it, because a skipped entry would be an instance that nothing manages, without a warning. For the same reason, unknown keys are rejected here, as everywhere else in the configuration. A misspelled entries: or awakeWindows: fails the configuration and does not silently manage nothing. Entries are validated even when enabled is false.

The rules:

• name: required, unique, lowercase letters, digits and hyphens.
• kind: a known kind, and its block is present.
• identifier: required, and unique per kind and effective region. The effective region is the region that the entry names, or the controller’s own region when it names none.
  • The same identifier in two named regions is two resources, and Hibernator manages both.
  • An identifier that appears once with a named region and once without is rejected as ambiguous. The validator cannot resolve an inherited region, so it does not guess.
• Durations: Go durations, greater than zero.
• wakePriority: at least 1.
• timezone: a valid IANA name.
• days: valid weekday names.
• start and end: different from each other. "24:00" is accepted as an end only.

Warning

Define each YAML anchor in the section that uses it. Hibernator reads databases, wakeOrdering and hibernateOrdering with a strict decoder that sees only that section. If an alias refers to an &anchor outside its section, the whole configuration fails with databases: decode failed: yaml: unknown anchor 'shared' referenced. The error names the anchor, not its position, and the YAML itself is valid. With the &anchor in the same section, the alias works: two entries can share one awakeWindows: block or one defaults: block.

Awake windows

An awake window keeps an instance available outside working hours, for example for a nightly batch job.

An end before the start spans midnight. 23:25-00:10 is one window, and its end falls on the next day. The days list names the day on which the window starts. So a [monday..friday] window covers Saturday 00:00-00:10 as the end of Friday night. It does not cover Monday 00:00-00:10, because the list does not name Sunday.

Ends are exclusive, so "24:00" means midnight at the end of the day. Use it for a window that stops at midnight and does not continue into the next day. Two adjacent windows written that way (22:00-24:00 on Monday, 00:00-06:00 on Tuesday) hand over at midnight with no gap. An end of "23:59" would leave the last minute of every night uncovered.

Daylight saving time

On the spring-forward day, a time inside the skipped hour becomes the moment the clocks jumped:

• A 02:00-06:00 window runs 03:00-06:00 that day.
• A 01:30-02:30 window ends at the jump.
• A window that lies fully inside the skipped hour, such as 02:15-02:45, is empty and does not occur. The next start is then the occurrence of the next week, not an empty value.

On the fall-back day, a time that the clocks repeat becomes its first occurrence:

• A 02:30-06:00 window is an up reason from the first 02:30, not one hour later.
• A 01:30-02:30 window ends at the first 02:30.
• A window that spans the repeated hour covers both.

A window that spans midnight can have its two ends on different sides of a clock change. Each end is corrected on its own date. The spring-forward night is one hour shorter than its clock times say, and the fall-back night is one hour longer.