Статьи

Kubernetes 1.8: Использование Cronjobs для создания резервных копий Neo4j

Ноябрь 19, 2018

С выпуском Kubernetes 1.8 Cronjobs перешли на бета-версию, что означает, что теперь мы можем более легко запускать задания резервного копирования Neo4j для кластеров Kubernetes.

Прежде чем мы научимся писать Cronjob, давайте сначала создадим локальный кластер Kubernetes и развернем Neo4j.

Spinup Kubernetes & Helm

1
2
minikube start --memory 8192
helm init && kubectl rollout status -w deployment/tiller-deploy --namespace=kube-system

Развернуть кластер Neo4j

1
2
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm install incubator/neo4j --name neo-helm --wait --set authEnabled=false,core.extraVars.NEO4J_dbms_backup_address=0.0.0.0:6362

Заполните наш кластер данными

Мы можем выполнить следующую команду, чтобы проверить, готов ли наш кластер:

01
02
03
04
05
06
07
08
09
10
11
kubectl exec neo-helm-neo4j-core-0 \
  -- bin/cypher-shell --format verbose \
  "CALL dbms.cluster.overview() YIELD id, role RETURN id, role"
  
+-----------------------------------------------------+
| id                                     | role       |
+-----------------------------------------------------+
| "0b3bfe6c-6a68-4af5-9dd2-e96b564df6e5" | "LEADER"   |
| "09e9bee8-bdc5-4e95-926c-16ea8213e6e7" | "FOLLOWER" |
| "859b9b56-9bfc-42ae-90c3-02cedacfe720" | "FOLLOWER" |
+-----------------------------------------------------+

Теперь давайте создадим некоторые данные:

1
2
3
4
5
6
kubectl exec neo-helm-neo4j-core-0 \
  -- bin/cypher-shell --format verbose \
  "UNWIND range(0,1000) AS id CREATE (:Person {id: id})"
  
0 rows available after 653 ms, consumed after another 0 ms
Added 1001 nodes, Set 1001 properties, Added 1001 labels

Теперь, когда наш кластер Neo4j работает и содержит данные, мы хотим регулярно делать резервные копии.

Резервные копии Neo4j

Инструмент резервного копирования Neo4j поддерживает полное и инкрементное резервное копирование.

Полная резервная копия

Полная резервная копия передает потоковую копию файлов хранилища в место резервного копирования и все транзакции, которые произошли во время резервного копирования. Эти транзакции затем применяются к резервной копии базы данных.

Инкрементное резервное копирование

Инкрементное резервное копирование запускается, если в хранилище резервных копий уже есть база данных Neo4j. В этом случае не будет копирования файлов магазина. Вместо этого инструмент будет копировать любые новые транзакции из Neo4j и применять их к резервной копии.

Резервное копирование

Мы будем использовать Cronjob для выполнения резервного копирования. В приведенном ниже примере мы присоединяем PersistentVolumeClaim к нашему Cronjob, чтобы мы могли видеть оба сценария резервного копирования в действии.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: backupdir-neo4j
  labels:
    app: neo4j-backup
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: neo4j-backup
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          volumes:
            - name: backupdir-neo4j
              persistentVolumeClaim:
                claimName: backupdir-neo4j
          containers:
            - name: neo4j-backup
              image: neo4j:3.3.0-enterprise
              env:
                - name: NEO4J_ACCEPT_LICENSE_AGREEMENT
                  value: "yes"
              volumeMounts:
              - name: backupdir-neo4j
                mountPath: /tmp
              command: ["bin/neo4j-admin",  "backup", "--backup-dir", "/tmp", "--name", "backup", "--from", "neo-helm-neo4j-core-2.neo-helm-neo4j.default.svc.cluster.local:6362"]
          restartPolicy: OnFailure
1
2
$ kubectl apply -f cronjob.yaml
cronjob "neo4j-backup" created
1
2
3
kubectl get jobs -w
NAME                      DESIRED   SUCCESSFUL   AGE
neo4j-backup-1510940940   1         1            34s

Теперь давайте посмотрим журналы с работы:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
kubectl logs $(kubectl get pods -a --selector=job-name=neo4j-backup-1510940940 --output=jsonpath={.items..metadata.name})
  
Doing full backup...
2017-11-17 17:49:05.920+0000 INFO [o.n.c.s.StoreCopyClient] Copying neostore.nodestore.db.labels
...
2017-11-17 17:49:06.038+0000 INFO [o.n.c.s.StoreCopyClient] Copied neostore.labelscanstore.db 48.00 kB
2017-11-17 17:49:06.038+0000 INFO [o.n.c.s.StoreCopyClient] Done, copied 18 files
2017-11-17 17:49:06.094+0000 INFO [o.n.b.BackupService] Start recovering store
2017-11-17 17:49:07.669+0000 INFO [o.n.b.BackupService] Finish recovering store
Doing consistency check...
2017-11-17 17:49:07.716+0000 INFO [o.n.k.i.s.f.RecordFormatSelector] Selected RecordFormat:StandardV3_2[v0.A.8] record format from store /tmp/backup
2017-11-17 17:49:07.716+0000 INFO [o.n.k.i.s.f.RecordFormatSelector] Format not configured. Selected format from the store: RecordFormat:StandardV3_2[v0.A.8]
2017-11-17 17:49:07.755+0000 INFO [o.n.m.MetricsExtension] Initiating metrics...
....................  10%
...
.................... 100%
Backup complete.

Пока все хорошо. Теперь давайте создадим больше данных:

1
2
3
4
5
6
7
kubectl exec neo-helm-neo4j-core-0 \
  -- bin/cypher-shell --format verbose \
  "UNWIND range(0,1000) AS id CREATE (:Person {id: id})"
  
  
0 rows available after 114 ms, consumed after another 0 ms
Added 1001 nodes, Set 1001 properties, Added 1001 labels

И дождитесь запуска другого задания резервного копирования:

1
2
3
4
5
kubectl get jobs -w
NAME                      DESIRED   SUCCESSFUL   AGE
neo4j-backup-1510941180   1         1            2m
neo4j-backup-1510941240   1         1            1m
neo4j-backup-1510941300   1         1            17s
01
02
03
04
05
06
07
08
09
10
11
kubectl logs $(kubectl get pods -a --selector=job-name=neo4j-backup-1510941300 --output=jsonpath={.items..metadata.name})
  
Destination is not empty, doing incremental backup...
Doing consistency check...
2017-11-17 17:55:07.958+0000 INFO [o.n.k.i.s.f.RecordFormatSelector] Selected RecordFormat:StandardV3_2[v0.A.8] record format from store /tmp/backup
2017-11-17 17:55:07.959+0000 INFO [o.n.k.i.s.f.RecordFormatSelector] Format not configured. Selected format from the store: RecordFormat:StandardV3_2[v0.A.8]
2017-11-17 17:55:07.995+0000 INFO [o.n.m.MetricsExtension] Initiating metrics...
....................  10%
...
.................... 100%
Backup complete.

Если бы мы продлили эту работу дальше, мы могли бы скопировать каждую резервную копию, которую требуется, в корзину S3, но я оставлю это на следующий день.

Опубликовано на Java Code Geeks с разрешения Марка Нидхэма, партнера нашей программы JCG . Смотреть оригинальную статью здесь: Kubernetes 1.8: Использование Cronjobs для создания резервных копий Neo4j

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

35
Share: