Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

... long live this repo #37

Merged
merged 18 commits into from
Dec 18, 2023
Merged

... long live this repo #37

merged 18 commits into from
Dec 18, 2023

Conversation

solsson
Copy link
Contributor

@solsson solsson commented Jun 25, 2021

Replaces #35 by evolving this repo's original stack, maintained by people with zero DBA skills 😄 . Closes #36 and #34.

solsson added 11 commits June 25, 2021 05:58
We use a pod monitor as below, and password by env override with for example

CREATE USER 'exporter'@'127.0.0.1' IDENTIFIED BY 'exporter' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'127.0.0.1';

An alternative would be to use socket+root, but the exporter runs
as nonroot properly and I'd recommend against making it root.

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: mariadb
  labels:
    prometheus: now
spec:
  jobLabel: app.kubernetes.io/name
  namespaceSelector:
    any: false
  selector:
    matchLabels:
      app: mariadb
  podMetricsEndpoints:
  - port: metrics
Also let's remove obsolete variants.

Note that scale-2 is not recommended as Galera cluster size.
when using an overlay with "namespace:"
I still think it's the default behavior, but maybe the entrypoint
script hasn't been updated to reflect the invalid-by-default root pwd.

Without these envs you get:

[ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
You need to specify one of MARIADB_ROOT_PASSWORD, MARIADB_ALLOW_EMPTY_ROOT_PASSWORD and MARIADB_RANDOM_ROOT_PASSWORD

This reverts commit ac5ffea.
solsson added a commit that referenced this pull request Aug 19, 2021
This reverts commit 109982e.

We should merge #37 and update variants accordingly,
because it reorganizes the main yaml so we can use a relative ref.
and as the comment suggested it actually caused downtime for a large state transfer
@solsson solsson merged commit fe56ddd into master Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bitnami stack in unrecoverable state after a node termination
1 participant