Thank you for reading this post, don't forget to subscribe!
самое главное - БАЗА В КОНТЕЙНЕРЕ - ЭТО ЗЛО !!!!!!!!!!!!!! мнение моё не обязательно правильное
Использование контейнерных баз данных в Kubernetes быстро и удобно.
Но как мы сможем обеспечить резервное копирование и восстановление работы?
Давайте рассмотрим это на моем любимом примере за последнее время, Sonarqube.
Предпосылки
- AKS работает с Sonarqube ( установка helm / sonarqube)
- вы используете (по умолчанию) контейнерную базу данных PostgreSQL
Определите ваш под PostgreSQL
Войдите в систему от имени администратора и зайдите в Administration -> System
Войти в Kubernetes;
$ az login
$ az aks get-credentials --name my-aks-cluster --resource-group my-aks-rg
Отобразите поды:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Get the pods $ kubectl get pods NAME READY STATUS RESTARTS AGE xxxxxxx-redis-infra-master-0 1/1 Running 0 106d xxxxxxx-redis-infra-slave-746fb58f8f-vlbwl 1/1 Running 4 106d xxxxxxx-sonarqube-db-infra-postgresql-5f6c845645-qknjq 1/1 Running 0 43d xxxxxxx-sonarqube-db-infra-sonarqube-64d465d5bb-4n74t 0/1 Evicted 0 43d xxxxxxx-sonarqube-db-infra-sonarqube-64d465d5bb-lt5c9 1/1 Running 0 1d xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7 1/1 Running 0 43d xxxxxxx-sonarqube-infra-sonarqube-78cdf5f6fd-whbdc 1/1 Running 1 43d elasticsearch-operator-sysctl-vckw5 1/1 Running 0 1d elasticsearch-operator-sysctl-z54kz 1/1 Running 0 1d |
Создание резервной копии PSQL
Вообще есть несколько способов, но проще всего использовать утилиты, которые, как мы знаем, существуют в поде базы данных.
|
1 2 3 4 5 6 7 8 9 10 |
$ kubectl exec -it xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7 -- /bin/sh # pg_dump sonarDB -f /tmp/db.out # ls -l /tmp/db.out -rw-r--r-- 1 root root 4938992 Mar 20 12:15 /tmp/db.out # ls -lh /tmp/db.out -rw-r--r-- 1 root root 4.8M Mar 20 12:15 /tmp/db.out # head -n10 /tmp/db.out -- -- PostgreSQL database dump |
Мы также можем сдампить все (хотя нам действительно нужна только база данных sonarDB – sonar не создает дополнительных пользователей базы данных)
# pg_dumpall -f /tmp/dball.out
# ls -lh /tmp/db*
-rw-r--r-- 1 root root 4.8M Mar 20 12:16 /tmp/dball.out
-rw-r--r-- 1 root root 4.8M Mar 20 12:15 /tmp/db.out
ПРИМЕЧАНИЕ. Базе данных Azure для PostgreSQL потребуется сжатая версия (полезно при переходе на предложение PaaS)
$ pg_dump -Fc -v --dbname=sonarDB > /tmp/114-try2.dump
Выйдите из поды и скопируйте файлы локально:
$ kubectl cp xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7:/tmp/db.out ./92-db.out
$ kubectl cp xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7:/tmp/dball.out ./92-dball.out
На данный момент у нас есть моментальное резервное копирование контейнерной базы данных.
Проверка
Удалите под и восстановите.
Это должно сбросить базу данных, и наш экземпляр должен храниться до нашего восстановления …
|
1 2 3 4 5 6 |
$ kubectl delete pod xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7 pod "xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-7twk7" deleted $ kubectl get pods | grep xxxxxxx-sonarqube-infra-postgresql xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-dtq8l 0/1 ContainerCreating 0 1m $ kubectl get pods | grep xxxxxxx-sonarqube-infra-postgresql xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-dtq8l 1/1 Running 0 15m |
Давайте подтвердим, что мы можем восстановиться из бэкапа.
MUG тестирование
(malicious user group – я уверен, что есть другие имена для этого типа тестирования, но я захотел использовать этот термин)
Плохой админ удаляет проект
Восстановление базы данных контейнера
Сначала мы копируем резервную копию в новую поду, а затем мы должны войти в систему и уничтожить соединения, чтобы мы могли удалить и восстановить существующую базу данных.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
$ kubectl cp ./92-db.out xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-dtq8l:/tmp/db.out $ kubectl exec -it xxxxxxx-sonarqube-infra-postgresql-6f58d97bdc-dtq8l -- /bin/sh # psql postgres psql (9.6.2) Type "help" for help. postgres=# UPDATE pg_database SET datallowconn = 'false' WHERE datname = 'sonarDB'; UPDATE 1 postgres=# SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'sonarDB'; pg_terminate_backend ---------------------- t t t t (4 rows) postgres=# DROP DATABASE "sonarDB"; DROP DATABASE \quit # createdb sonarDB # psql sonarDB < /tmp/db.out |
Наконец, мы должны снова включить соединения (иначе Sonarqube не сможет ее использовать):
|
1 2 3 |
postgres=# UPDATE pg_database SET datallowconn = 'true' WHERE datname = 'sonarDB'; UPDATE 1 postgres=# \quit |
Теперь вы можете подумать, что простой перезапуск обрезжет базу;
Но сервер кеширует много данных для производительности.
Единственный верный способ убедиться, что SonarQube извлекает свежие данные из базы данных, – это убить саму поду SonarQube и обновить его:
|
1 2 3 4 |
$ kubectl delete pod xxxxxxx-sonarqube-infra-sonarqube-78cdf5f6fd-whbdc pod "xxxxxxx-sonarqube-infra-sonarqube-78cdf5f6fd-whbdc" deleted $ kubectl get pods | grep sonarqube-infra-sonarqube xxxxxxx-sonarqube-infra-sonarqube-78cdf5f6fd-7tfmp 1/1 Running 0 3m |
Когда сервис поднимется, мы действительно увидим, что удаленный проект был восстановлен:
Загрузка базы данных Azure для PostgreSQL с данными из бэкапа контейнера.
Во-первых, убедитесь, что резервное копирование пода со сжатием, если вы не проверили ранее
pg_dump -Fc -v --dbname=sonarDB > /tmp/mydump.dump
Вы можете использовать SSH в поде для восстановления (или сделать это локально).
Вам нужно принудительно установить SSL, если это требуется вашей базе данных Azure
$ export PGSSLMODE=require
$ pg_restore -v --no-owner --host=sonar.postgres.database.azure.com --port=5432 --username=sonar