Skip to content

Redis Replication

Angeheftet Verschoben Redis
  • Spielen wir mal folgendes Szenario durch, wir haben eine Redis Datenbank und möchten diese Datenbank irgendwo anders nochmal haben. Nennen wir es eine Sicherung. Redis hat dafür eine Master/Slave Möglichkeit eingebaut.

    Ok, wir wissen das es nicht gut ist im Internet Daten im Klartext von einem Server zum nächsten zu schicken. Also brauchen wir etwas verschlüsseltes 😉 Dazu habe ich mich ja ein wenig mit Wireguard beschäftigt Beitrag

    Damit haben wir also eine Möglichkeit von Server1 (Master) zum Server2 (Slave) eine verschlüsselte Verbindung aufzubauen und das ohne großen Aufwand.

    Die Konfiguration von Redis ist recht einfach zu erledigen.

    Server 1 MASTER

    /etc/redis/redis.conf

    Ich gehe hier nur auf die Parameter ein, die für die Replication wichtig sind!

    bind 127.0.0.1 ::1 192.168.10.1
    

    Hier sehen wir drei IP-Adressen.

    • 127.0.0.1 localhost
    • ::1 Das gleiche für IPv6
    • 192.168.10.1

    Die ersten beiden sind Standard, die dritte habe ich erweitert. Dabei handelt sich um meine Wireguard IP-Adresse, die im privaten Netz 192.168.10.x liegt.

    Diese DB hat ein Passwort

    requirepass XXXXXXXXXXXX
    

    Nach den Änderungen den Dienst Redis kurz neustarten.

    service redis restart
    

    Das war's.

    Server 2 SLAVE

    /etc/redis/redis.conf

    Hier ist es nicht nötig eine IP-Adresse anzugeben.

    bind 127.0.0.1 ::1
    

    Der Master muss ja auf der Schnittstelle lauschen, ob da was für ihn ankommt. Der Slave nimmt einfach über die Wireguard Schnittstelle wg0 die Verbindung auf.

    slaveof 192.168.10.1  6379
    

    Hiermit definieren wir, welcher Rechner im Netz der Master ist. In diesem Fall 192.168.10.1, meine Wireguard-Adresse. Der Port ist Standard 6379.

    Damit weiß der Slave wo er den Master erreichen kann. Dazu nimmt er über die Schnittstelle wg0 Verbindung mit dem Rechner auf der IP-Adresse 192.168.10.1 auf. Also nutzt er die verschlüsselte Verbindung von Wireguard.

    Da der Master passwortgeschützt ist, muss der Slave natürlich das PW kennen, ohne bekommt er ja keine Verbindung. Dafür nutzt Redis folgenden Befehl.

    masterauth XXXXXXXXXX
    

    Das alles speichern und den Dienst neustarten.

    service redis restart
    

    In derselben Sekunde wo der Dienst neugestartet wird, ist die DB auch schon da.

    Vorher

    root@rp_64_test:/etc/redis# ls -la /var/lib/redis
    total 12
    drwxr-x---  2 redis redis 4096 Mar 21 16:05 .
    drwxr-xr-x 27 root  root  4096 Mar 21 15:59 ..
    -rw-rw----  1 redis redis   92 Mar 21 16:05 dump.rdb
    

    Nachher

    root@rp_64_test:/etc/redis# ls -la /var/lib/redis
    total 7020
    drwxr-x---  2 redis redis    4096 Mar 21 16:09 .
    drwxr-xr-x 27 root  root     4096 Mar 21 15:59 ..
    -rw-r-----  1 redis redis 7178902 Mar 21 16:09 dump.rdb
    

    Vom Master der Datentransfer über wg0

    Vorher

    root@rp64_nextcloud:~# wg
    interface: wg0
      public key: gqiCgt5+X3na+wZ1e9gnR1pTujFO3jIudnwDIttDPEo=
      private key: (hidden)
      listening port: 35866
    
    peer: zj1ajjcBhgFSe+NUHtnTNQ4+emsVgHDPVOeQHVKK4U4=
      endpoint: 192.168.3.14:39717
      allowed ips: 192.168.10.2/32
      latest handshake: 10 seconds ago
      transfer: 19.04 KiB received, 21.66 KiB sent
    

    Nachher

    root@rp64_nextcloud:/etc/redis# wg
    interface: wg0
      public key: gqiCgt5+X3na+wZ1e9gnR1pTujFO3jIudnwDIttDPEo=
      private key: (hidden)
      listening port: 35866
    
    peer: zj1ajjcBhgFSe+NUHtnTNQ4+emsVgHDPVOeQHVKK4U4=
      endpoint: 192.168.3.14:39717
      allowed ips: 192.168.10.2/32
      latest handshake: 59 seconds ago
      transfer: 120.10 KiB received, 7.33 MiB sent
    

    Er hat die Datenbank, ca. 6,9 MB groß, zum Slave gesendet.

    Master

    root@rp64_nextcloud:/etc/redis# ls -lha /var/lib/redis
    total 6,9M
    drwxr-x---  2 redis redis 4,0K Mär 21 17:09 .
    drwxr-xr-x 29 root  root  4,0K Mär  2 12:52 ..
    -rw-rw----  1 redis redis 6,9M Mär 21 17:09 dump.rdb
    

    Slave

    root@rp_64_test:/etc/redis# ls -lha /var/lib/redis
    total 6.9M
    drwxr-x---  2 redis redis 4.0K Mar 21 16:09 .
    drwxr-xr-x 27 root  root  4.0K Mar 21 15:59 ..
    -rw-r-----  1 redis redis 6.9M Mar 21 16:09 dump.rdb
    

    Und wg0

    root@rp_64_test:/etc/redis# wg
    interface: wg0
      public key: zj1ajjcBhgFSe+NUHtnTNQ4+emsVgHDPVOeQHVKK4U4=
      private key: (hidden)
      listening port: 39717
    
    peer: gqiCgt5+X3na+wZ1e9gnR1pTujFO3jIudnwDIttDPEo=
      endpoint: 192.168.3.208:35866
      allowed ips: 192.168.10.1/32
      latest handshake: 1 minute, 4 seconds ago
      transfer: 7.32 MiB received, 110.20 KiB sent
    

    Fertig! Eine nette Sache, eine Redis Datenbank zu sichern.

    Und zum Schluß, der Slave ist standardmäßig read-only. Der sollte also am Master nichts kaputt machen.

    # Since Redis 2.6 by default slaves are read-only.
    #
    # Note: read only slaves are not designed to be exposed to untrusted clients
    # on the internet. It's just a protection layer against misuse of the instance.
    # Still a read only slave exports by default all the administrative commands
    # such as CONFIG, DEBUG, and so forth. To a limited extent you can improve
    # security of read only slaves using 'rename-command' to shadow all the
    # administrative / dangerous commands.
    slave-read-only yes
    

    Quelle: https://redis.io/topics/replication

  • Wenn man NodeBB-Foren betreibt, sollte die Vorgehensweise so sein.

    • Redis Master starten
    • Redis Slave starten
    • Danach erst die Foren!!

    Wieder was gelernt 🙂

  • In den Logs sieht das so aus.

    Master

    855:M 10 May 2020 07:51:45.458 * DB loaded from disk: 0.563 seconds
    855:M 10 May 2020 07:51:45.458 * Ready to accept connections
    855:M 10 May 2020 07:51:45.713 * Replica 10.0.0.2:6379 asks for synchronization
    855:M 10 May 2020 07:51:45.713 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'd6042ec68cc9b4e3ccd8ebd8e28012133c24efb4', my replication IDs are '071743$
    855:M 10 May 2020 07:51:45.713 * Starting BGSAVE for SYNC with target: disk
    855:M 10 May 2020 07:51:45.716 * Background saving started by pid 859
    859:C 10 May 2020 07:51:46.107 * DB saved on disk
    859:C 10 May 2020 07:51:46.111 * RDB: 24 MB of memory used by copy-on-write
    855:M 10 May 2020 07:51:46.162 * Background saving terminated with success
    855:M 10 May 2020 07:51:46.324 * Synchronization with replica 10.0.0.2:6379 succeeded
    855:M 10 May 2020 07:51:50.674 # Connection with replica 10.0.0.2:6379 lost.
    855:M 10 May 2020 07:51:51.254 * Replica 10.0.0.2:6379 asks for synchronization
    855:M 10 May 2020 07:51:51.255 * Partial resynchronization request from 10.0.0.2:6379 accepted. Sending 0 bytes of backlog starting from offset 1.
    855:M 10 May 2020 07:56:47.021 * 10 changes in 300 seconds. Saving...
    855:M 10 May 2020 07:56:47.023 * Background saving started by pid 978
    978:C 10 May 2020 07:56:47.426 * DB saved on disk
    978:C 10 May 2020 07:56:47.428 * RDB: 28 MB of memory used by copy-on-write
    855:M 10 May 2020 07:56:47.529 * Background saving terminated with success
    855:M 10 May 2020 07:56:52.961 # Connection with replica 10.0.0.2:6379 lost.
    855:M 10 May 2020 07:56:53.649 * Replica 10.0.0.2:6379 asks for synchronization
    855:M 10 May 2020 07:56:53.649 * Partial resynchronization request from 10.0.0.2:6379 accepted. Sending 0 bytes of backlog starting from offset 6413.
    855:M 10 May 2020 08:01:48.089 * 10 changes in 300 seconds. Saving...
    855:M 10 May 2020 08:01:48.091 * Background saving started by pid 1044
    1044:C 10 May 2020 08:01:48.502 * DB saved on disk
    1044:C 10 May 2020 08:01:48.505 * RDB: 24 MB of memory used by copy-on-write
    855:M 10 May 2020 08:01:48.594 * Background saving terminated with success
    

    Slave

    1324:S 10 May 2020 07:56:53.651 * DB loaded from disk: 0.638 seconds
    1324:S 10 May 2020 07:56:53.651 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partia$
    1324:S 10 May 2020 07:56:53.651 * Ready to accept connections
    1324:S 10 May 2020 07:56:53.651 * Connecting to MASTER 10.0.0.4:6379
    1324:S 10 May 2020 07:56:53.651 * MASTER <-> REPLICA sync started
    1324:S 10 May 2020 07:56:53.652 * Non blocking connect for SYNC fired the event.
    1324:S 10 May 2020 07:56:53.653 * Master replied to PING, replication can continue...
    1324:S 10 May 2020 07:56:53.654 * Trying a partial resynchronization (request 86ba864a2575c203a4eddd80bd6f4b058ebe1fb7:6413).
    1324:S 10 May 2020 07:56:53.655 * Successful partial resynchronization with master.
    1324:S 10 May 2020 07:56:53.655 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.
    1324:S 10 May 2020 08:01:54.077 * 10 changes in 300 seconds. Saving...
    1324:S 10 May 2020 08:01:54.080 * Background saving started by pid 1494
    1494:C 10 May 2020 08:01:54.523 * DB saved on disk
    1494:C 10 May 2020 08:01:54.527 * RDB: 0 MB of memory used by copy-on-write
    1324:S 10 May 2020 08:01:54.582 * Background saving terminated with success
    
  • Um die Verbindung zu testen, kann man folgende Befehle nutzen.

    redis-cli -h 10.1.1.0 -p 6379 -a <PASSWORD>
    

    und

    telnet 10.1.1.0 6379
    

  • NAS 2023 - Thema Datensicherung

    Verschoben Linux
    2
    0 Stimmen
    2 Beiträge
    120 Aufrufe
    FrankMF

    Bleibt noch etwas wichtiges. Die ganzen Konfigurationsdateien vom Proxmox Host. Sinnvoll, das man sich das sichert.

    #!/bin/bash # Script um mit Restic Daten automatisiert zu sichern! # Dient zum Sichern des Ordners /etc/pve! # Was soll gesichert werden? backup_pfad=/etc/pve # Programm Start restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve backup $backup_pfad > backup_pve_001.log restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve forget --keep-last 3 --keep-monthly 3 --prune >> backup_pve_002.log # Testen restic --password-file /root/passwd -r /mnt/pve/Restic_Backups/pve check --read-data >> backup_pve_003.log

    Crontab eingerichtet - fertig!

  • Ubuntu 21.04 (Hirsute Hippo) Beta

    Linux
    6
    0 Stimmen
    6 Beiträge
    432 Aufrufe
    FrankMF

    Seit heute ist Ubuntu mal wieder Geschichte. Bin wieder zurück auf Linux Mint Cinnamon.

    Die zwei wichtigsten Gründen

    Wenn ich unter Ubuntu (Wayland) VLC zum TV schauen an geschmissen habe, war in unregelmäßigen Abständen das UI in mehreren Fenster aufgegangen. Blöd nur, das man das TV Bild nicht zoomen konnte. Das Hauptproblem! Ab und zu passierte es, wenn ich auf das Firefox Icon geklickt habe, das der ganze Desktop einen Freeze hatte. Incl. unbenutzbarer Tastatur und Maus. Blieb dann leider nur der Reset. Blöd nur, das das immer dann passierte, wenn man es gerade gar nicht gebrauchen konnte.

    Bin dann wieder auf eine hoffentlich stabilere Distribution zurück gegangen. Nun wieder als X-Desktop. Wayland ist die Zukunft, da dort die Latenzen um Längen besser sind, als unter X. Aber, es bedarf da noch einer gewissen Entwicklungszeit. Wollen wir hoffen, das mit dem nächsten Ubuntu Release die Kinderkrankheiten ausgemerzt sind.

    d74e1c43-2a70-4ef0-ace5-7d8ac2c3e99a-grafik.png

  • 0 Stimmen
    1 Beiträge
    537 Aufrufe
    Niemand hat geantwortet
  • Rest-Server

    Verschoben Restic
    8
    0 Stimmen
    8 Beiträge
    541 Aufrufe
    FrankMF

    Dann mal eben ausprobiert. Auf meinem Server war die Version 0.9.7 selber, mit go, gebaut. Dann mache ich das auch mit der v0.10.0 so. Aber bevor ich anfange, wird die v0.9.7 gesichert.

    mv /usr/local/bin/rest-server /usr/local/bin/rest-server_0_9_7

    So erspare ich mir im Problemfall das selber bauen.

    Ok, dann die neue Version bauen.

    git clone https://github.com/restic/rest-server.git cd rest-server go run build.go

    Danach befindet sich im Verzeichnis die Binärdatei rest-server

    Die kopieren wir jetzt

    cp rest-server /usr/local/bin

    Danach kurzer Test

    # rest-server --version rest-server 0.10.0 (v0.10.0-6-g037fe06) compiled with go1.11.6 on linux/amd64

    Gut Version passt 🙂

    Dann ein Backup gestartet. Das sichert einen Teil meines Home-Verzeichnis

    Files: 153 new, 100 changed, 177857 unmodified Dirs: 0 new, 1 changed, 0 unmodified Added to the repo: 81.881 MiB processed 178110 files, 80.571 GiB in 0:28 snapshot 607e0027 saved Applying Policy: keep the last 3 snapshots, 3 monthly snapshots keep 5 snapshots: ID Time Host Tags Reasons Paths --------------------------------------------------------------------------------------- fa97890e 2020-07-25 21:02:05 frank-XXX monthly snapshot /home/frank 5b073bbb 2020-08-30 10:17:27 frank-XXX monthly snapshot /home/frank f7cf37ef 2020-09-06 15:13:03 frank-XXX last snapshot /home/frank 0157462c 2020-09-13 13:32:12 frank-XXX last snapshot /home/frank 607e0027 2020-09-14 08:09:34 frank-XXX last snapshot /home/frank monthly snapshot --------------------------------------------------------------------------------------- 5 snapshots remove 1 snapshots: ID Time Host Tags Paths --------------------------------------------------------------------- 3010b7cc 2020-09-06 11:39:27 frank-XXX /home/frank --------------------------------------------------------------------- 1 snapshots 1 snapshots have been removed, running prune counting files in repo building new index for repo [1:34] 100.00% 17351 / 17351 packs

    So weit funktioniert das genau wie vorher. Im Changelog stand ja was von Subfoldern. Das betrifft mich nicht, weil ich für jeden User genau ein Verzeichnis habe.

    So mit alles Gut 🙂 Dann warte ich mal morgen ab, ob die täglichen Backups der Server rund laufen.

  • IPTables dauerhaft speichern

    Angeheftet Linux
    1
    0 Stimmen
    1 Beiträge
    442 Aufrufe
    Niemand hat geantwortet
  • Wenn dir der Redis-Server flöten geht....

    Verschoben Redis
    3
    0 Stimmen
    3 Beiträge
    526 Aufrufe
    FrankMF

    So, nach einer kleinen Pause und ein wenig nachdenken ist mir doch noch was eingefallen 😉

    Backports! Man so einfach!

    nano /etc/apt/sources.list

    Das folgende eintragen.

    # backports deb http://deb.debian.org/debian stretch-backports main

    Danach ein

    apt update

    Und dann schauen wir uns mal die Version an....

    apt -t stretch-backports search redis-server Sorting... Done Full Text Search... Done golang-github-stvp-tempredis-dev/stretch-backports 0.0~git20160122.0.83f7aae-1~bpo9+1 all Go package to start and stop temporary redis-server processes libtest-redisserver-perl/oldstable,oldstable 0.20-1 all redis-server runner for tests python-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python 2.X using hiredis python3-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python using hiredis redis/stretch-backports 5:5.0.3-3~bpo9+2 all Persistent key-value database with network interface (metapackage) redis-server/stretch-backports 5:5.0.3-3~bpo9+2 amd64 [residual-config] Persistent key-value database with network interface

    Und die habe ich gestern Abend gebaut.

    127.0.0.1:6379> INFO # Server redis_version:5.0.5

    Ok, das schmerzt jetzt 😛

  • Redis installieren

    Angeheftet Verschoben Redis
    1
    0 Stimmen
    1 Beiträge
    360 Aufrufe
    Niemand hat geantwortet
  • NVMe Firmware - Daten werden benötigt

    Linux
    1
    0 Stimmen
    1 Beiträge
    702 Aufrufe
    Niemand hat geantwortet