VladPolskiy/mariadb-operator
1
0
Fork 0
mirror of https://github.com/mariadb-operator/mariadb-operator.git synced 2025-07-22 18:27:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix example links

Browse Source
This commit is contained in:
Martin Montes
2024-02-28 12:25:34 +01:00
parent 27f0f8af9d
commit e2a5e78946
5 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
README.md
View File

@ -21,8 +21,8 @@
# 🦭 mariadb-operator
Run and operate MariaDB in a cloud native way. Declaratively manage your MariaDB using Kubernetes [CRDs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) rather than imperative commands.
- [Easily provision](./examples/manifests/mariadb_v1alpha1_mariadb_minimal.yaml) MariaDB servers in Kubernetes.
- [Highly configurable](./examples/manifests/mariadb_v1alpha1_mariadb_full.yaml) MariaDB servers.
- [Easily provision](./examples/manifests/mariadb_minimal.yaml) MariaDB servers in Kubernetes.
- [Highly configurable](./examples/manifests/mariadb_full.yaml) MariaDB servers.
- Multiple [HA modes](./docs/HA.md): SemiSync Replication and Galera.
- Automatic [primary failover](./docs/HA.md).
- Enhanced HA with [MaxScale](./docs/MAXSCALE.md): a sophisticated database proxy, router, and load balancer designed specifically for and by MariaDB.
@ -38,8 +38,8 @@ Run and operate MariaDB in a cloud native way. Declaratively manage your MariaDB
- [Target recovery time](./docs/BACKUP.md#target-recovery-time): infer which backup to restore.
- [Bootstrap new instances](./docs/BACKUP.md#bootstrap-new-mariadb-instances-from-backups) from: Backups, S3, PVCs ...
- [Prometheus metrics](./docs/METRICS.md) via [mysqld-exporter](https://github.com/prometheus/mysqld_exporter).
- Manage [users](./examples/manifests/mariadb_v1alpha1_user.yaml), [grants](./examples/manifests/mariadb_v1alpha1_grant.yaml) and logical [databases](./examples/manifests/mariadb_v1alpha1_database.yaml).
- Configure [connections](./examples/manifests/mariadb_v1alpha1_connection.yaml) for your applications.
- Manage [users](./examples/manifests/user.yaml), [grants](./examples/manifests/grant.yaml) and logical [databases](./examples/manifests/database.yaml).
- Configure [connections](./examples/manifests/connection.yaml) for your applications.
- Orchestrate and schedule [sql scripts](./examples/manifests/sqljobs).
- Validation webhooks to provide CRD inmutability.
- Additional printer columns to report the current CRD status.
@ -83,7 +83,7 @@ kubectl apply -f examples/manifests/config
Next, you can proceed with the installation of a `MariaDB` instance:
```bash
kubectl apply -f examples/manifests/mariadb_v1alpha1_mariadb.yaml
kubectl apply -f examples/manifests/mariadb.yaml
```
```bash
kubectl get mariadbs
@ -100,9 +100,9 @@ mariadb ClusterIP 10.96.235.145 <none> 3306/TCP,9104/TCP 2m17s
```
Up and running 🚀, we can now create our first logical database and grant access to users:
```bash
kubectl apply -f examples/manifests/mariadb_v1alpha1_database.yaml
kubectl apply -f examples/manifests/mariadb_v1alpha1_user.yaml
kubectl apply -f examples/manifests/mariadb_v1alpha1_grant.yaml
kubectl apply -f examples/manifests/database.yaml
kubectl apply -f examples/manifests/user.yaml
kubectl apply -f examples/manifests/grant.yaml
```
```bash
kubectl get databases
@ -141,7 +141,7 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
Now that the database has been initialized, let's take a backup:
```bash
kubectl apply -f examples/manifests/mariadb_v1alpha1_backup.yaml
kubectl apply -f examples/manifests/backup.yaml
```
```bash
kubectl get backups
@ -154,7 +154,7 @@ backup-27782894 1/1 4s 3m2s
```
Last but not least, let's provision a second `MariaDB` instance bootstrapping from the previous backup:
```bash
kubectl apply -f examples/manifests/mariadb_v1alpha1_mariadb_from_backup.yaml
kubectl apply -f examples/manifests/mariadb_from_backup.yaml
```
```bash
kubectl get mariadbs

8
docs/BACKUP.md
View File

@ -10,11 +10,11 @@ Refer to the sections below, the [API reference](./API_REFERENCE.md) and the [ex
## Storage types
Currently, the following storage types are supported:
- **[S3](../examples/manifests/mariadb_v1alpha1_backup.yaml) compatible storage**: Store backups in a S3 compatible storage, such as [AWS S3](https://aws.amazon.com/s3/) or [Minio](https://github.com/minio/minio).
- **[PVCs](../examples/manifests/mariadb_v1alpha1_backup_pvc.yaml)**: Use the available [StorageClasses](https://kubernetes.io/docs/concepts/storage/storage-classes/) in your Kubernetes cluster to provision a PVC dedicated to store the backup files.
- **[Kubernetes volumes](../examples/manifests/mariadb_v1alpha1_backup_nfs.yaml)**: Use any of the [volume types](https://kubernetes.io/docs/concepts/storage/volumes/#volume-types) supported natively by Kubernetes.
- **[S3](../examples/manifests/backup.yaml) compatible storage**: Store backups in a S3 compatible storage, such as [AWS S3](https://aws.amazon.com/s3/) or [Minio](https://github.com/minio/minio).
- **[PVCs](../examples/manifests/backup_pvc.yaml)**: Use the available [StorageClasses](https://kubernetes.io/docs/concepts/storage/storage-classes/) in your Kubernetes cluster to provision a PVC dedicated to store the backup files.
- **[Kubernetes volumes](../examples/manifests/backup_nfs.yaml)**: Use any of the [volume types](https://kubernetes.io/docs/concepts/storage/volumes/#volume-types) supported natively by Kubernetes.
Our recommendation is to store the backups externally in a [S3](../examples/manifests/mariadb_v1alpha1_backup.yaml) compatible storage. [Minio](https://github.com/minio/minio) makes this incredibly easy, take a look at our [Minio reference installation](#minio-reference-installation) to quickly spin up an instance.
Our recommendation is to store the backups externally in a [S3](../examples/manifests/backup.yaml) compatible storage. [Minio](https://github.com/minio/minio) makes this incredibly easy, take a look at our [Minio reference installation](#minio-reference-installation) to quickly spin up an instance.
## `Backup`

6
docs/GALERA.md
View File

@ -14,7 +14,7 @@ To be able to effectively provision and recover MariaDB Galera clusters, the fol
## Configuration
The easiest way to get a MariaDB Galera cluster up and running is setting `spec.galera.enabled = true`, like in this [example](../examples/manifests/mariadb_v1alpha1_mariadb_galera_minimal.yaml):
The easiest way to get a MariaDB Galera cluster up and running is setting `spec.galera.enabled = true`, like in this [example](../examples/manifests/mariadb_galera_minimal.yaml):
```yaml
apiVersion: k8s.mariadb.com/v1alpha1
@ -28,7 +28,7 @@ spec:
...
```
This relies on sensible defaults set by either the operator or the webhook, which may not be suitable for your Kubernetes cluster. This can be solved by overriding the defaults, as in this other [example](../examples/manifests/mariadb_v1alpha1_mariadb_galera.yaml), so you have fine-grained control over the Galera configuration:
This relies on sensible defaults set by either the operator or the webhook, which may not be suitable for your Kubernetes cluster. This can be solved by overriding the defaults, as in this other [example](../examples/manifests/mariadb_galera.yaml), so you have fine-grained control over the Galera configuration:
```yaml
@ -81,7 +81,7 @@ kubectl apply -f examples/manifests/config
```
Next, you can proceed with the installation of a `MariaDB` instance with Galera support:
```bash
kubectl apply -f examples/manifests/mariadb_v1alpha1_mariadb_galera.yaml
kubectl apply -f examples/manifests/mariadb_galera.yaml
```
```bash
kubectl get mariadbs

4
docs/HA.md
View File

@ -4,14 +4,14 @@ Our recommended HA setup for production is:
- **[Galera](./GALERA.md)** with at least 3 replicas.
- Load balance requests using **[MaxScale](./MAXSCALE.md)** as database proxy.
- Configure **[pod anti affinity](#pod-anti-affinity)** to schedule your `Pods` in different Kubernetes `Nodes`.
- Define **[pod disruption budgets]()**.
- Define **[pod disruption budgets](#pod-disruption-budgets)**.
- Use **[dedicated nodes](#dedicated-nodes)** to avoid noisy neighbours.
Refer to the following sections for further detail.
## Supported HA modes
- **Single master HA via [SemiSync Replication](../examples/manifests/mariadb_v1alpha1_mariadb_replication.yaml)**: The primary node allows both reads and writes, while secondary nodes only allow reads.
- **Single master HA via [SemiSync Replication](../examples/manifests/mariadb_replication.yaml)**: The primary node allows both reads and writes, while secondary nodes only allow reads.
- **Multi master HA via [Galera](./GALERA.md)**: All nodes support reads and writes. We have a designated primary where the writes are performed in order to avoid deadlocks.
## Kubernetes Services

4
docs/METRICS.md
View File

@ -26,7 +26,7 @@ As you scale your MariaDB with more or less replicas, `mariadb-operator` will re
## Configuration
The easiest way to setup metrics in your MariaDB instance is just by setting `spec.metrics.enabled = true`, like in this [example](../examples/manifests/mariadb_v1alpha1_mariadb_metrics.yaml):
The easiest way to setup metrics in your MariaDB instance is just by setting `spec.metrics.enabled = true`, like in this [example](../examples/manifests/mariadb_metrics.yaml):
```yaml
apiVersion: k8s.mariadb.com/v1alpha1
@ -39,7 +39,7 @@ spec:
enabled: true
```
The rest of the fields are defaulted by the operator. If you need a more fine grained configuration, refer to the [API reference](./API_REFERENCE.md) and take a look at this [example](../examples/manifests/mariadb_v1alpha1_mariadb_metrics_full.yaml):
The rest of the fields are defaulted by the operator. If you need a more fine grained configuration, refer to the [API reference](./API_REFERENCE.md) and take a look at this [example](../examples/manifests/mariadb_metrics_full.yaml):
```yaml
apiVersion: k8s.mariadb.com/v1alpha1