# MySQL Operator for Kubernetes Installation

## Using Manifest Files with kubectl

First deploy the Custom Resource Definition (CRDs):

    kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/9.6.0-2.2.7/deploy/deploy-crds.yaml

Then deploy MySQL Operator for Kubernetes:

    kubectl apply -f https://raw.githubusercontent.com/mysql/mysql-operator/9.6.0-2.2.7/deploy/deploy-operator.yaml

Verify the operator is running by checking the deployment inside the mysql-operator namespace:

    kubectl get deployment -n mysql-operator mysql-operator

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    mysql-operator   1/1     1            1           1h


# MySQL InnoDB Cluster Installation

## Using kubectl

For creating a MySQL InnoDB Cluster, first create a secret with credentials for a MySQL root user used to perform administrative tasks in the cluster. For example:

    kubectl create secret generic mypwds \
        --from-literal=rootUser=root \
        --from-literal=rootHost=% \
        --from-literal=rootPassword="sakila"

Define your MySQL InnoDB Cluster, which references the secret. For example:

    apiVersion: mysql.oracle.com/v2
    kind: InnoDBCluster
    metadata:
      name: mycluster
    spec:
      secretName: mypwds
      tlsUseSelfSigned: true
      instances: 3
      router:
        instances: 1

Assuming it's saved as mycluster.yaml, deploy it:

    kubectl apply -f mycluster.yaml

This sample creates an InnoDB Cluster with three MySQL Server instances and one MySQL Router instance. The process can be observed using:

    kubectl get innodbcluster --watch

    NAME          STATUS    ONLINE   INSTANCES   ROUTERS   AGE
    mycluster     PENDING   0        3           1         2m6s
    ...
    mycluster     ONLINE    3        3           1         10s

# Conectar al cluster


    kubectl run --rm -it myshell --image=container-registry.oracle.com/mysql/community-operator -- mysqlsh

en el prompt,

    \connect root@mycluster-instances.mysql-cluster.svc.cluster.local

> NOTA: el nombre del host es el del servicio del cluster (```mycluster-instances```) seguido del namespace (```mysql-cluster```) y finalmente por ```svc.cluster.local```.

## PHP my admin

Como php my admin tiene que trabajar con el cluster, no hace falta tener uno en cada wordpress. Solo hay una instancia y está aquí

# Trabajar con bases de datos

## Exportar e importar

Parece ser que phpmyadmin no especifica PRIMARY KEY en las sentencias de creación de tabla, lo cual es necesario para luego importar las tablas en InnoDB.

La solución es hacerlo a mano:

    mysqldump -h $PMA_HOST -p wordpress --single-transaction --ssl-verify-server-cert=false > wordpress.sql

> 'wordpress' es el nombre de la base de datos.

Para ejecutar ```mysqldump```, hay que entrar en el contenedor de phpmyadmin (puede que también valga con mysql shell, aunque aquí no sé cómo copiar el sql al disco local)

    kubectl -n mysql-cluster exec -it deployment.apps/phpmyadmin-mysql-cluster -- bash

Si, por lo que sea, el phpmyadmin lo acabamos de crear, entonces habrá que instalar el cliente ```mariadb-client```.

    apt update
    apt install -y mariadb-client

Finalmente, para 'sacar' el sql del contenedor:

    kubectl -n mysql-cluster cp `kubectl -n mysql-cluster get pods |grep phpmyadmin|cut -f1 -d' '`:/var/www/html/wordpress.sql ./wordpress.sql

> nuevamente, 'wordpress.sql' es el nombre que le dimos en el paso anterior

o también se puede ejecutar el comando siguiente que no necesita entrar, volcar, salir y extraer (este método funcionó bien con una base de datos pequeña. Con una grande como la de nueroreevolution, falló):

    kubectl -n mysql-cluster exec -it deployment.apps/phpmyadmin-mysql-cluster -- mysqldump -h mycluster-instances.mysql-cluster.svc.cluster.local -pDsa-0213  wordpress --single-transaction --ssl-verify-server-cert=false  > wordpress.sql