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
    

  • Redis ändert das Lizenz Modell

    Redis
    2
    0 Stimmen
    2 Beiträge
    37 Aufrufe
    FrankMF

    Ein Artikel von Heise zum Thema

    Link Preview Image Datenbankanbieter Redis ändert sein Lizenzmodell – erneut

    Die No-SQL-Datenbank wird künftig nach einem dualen Modell lizenziert: Redis Source Available License Version 2 oder Server-Side Public License Version 1.​

    favicon

    Developer (www.heise.de)

  • Redis - Datenbank Zugriff mit Python

    Redis
    3
    0 Stimmen
    3 Beiträge
    92 Aufrufe
    FrankMF

    Ich bin mit der Lernkurve noch nicht so richtig zufrieden. Eine Frage die sich mir stellte, geht das einfacher? Der Ursprung meiner Datenbank Struktur liegt in einem anderen Projekt, wo ich versucht habe Daten permanent in einem File zu speichern. Dazu hatte ich damals JSON genommen. Deswegen auch diese Zeilen

    self.project = str(db_client.json().get('settings', '$..project')[0]) or self.project

    Gut, ich hatte dann mal ChatGPT gefragt, wie macht man das so 'normalerweise'? es kam eine Klasse heraus, die ich dann intensiv ausprobiert habe, ein wenig umgebaut usw. So lange, bis ich der Meinung war, ok ich habe es verstanden. Jetzt nutzte der Code auch mehr Redis Funktionen, wie

    self.client.hset('settings', name, json.dumps(data))

    Es waren jetzt folgende Funktionen drin

    hset hexists hdel hget

    Dokumentation -> https://redis.io/commands/hset/

    Beim Durchlesen des Codes hatte ich jetzt mehr das Gefühl, so muss das sein 🙂

    In RedisInsight sieht das dann jetzt so aus.

    393195f7-1017-4285-8fca-734ee6b4bff7-grafik.png

    Klasse class PortfolioSettings: def __init__(self, host='172.17.0.2', port=6379, db=0): if args.test_mode == 1: self.client = redis.StrictRedis(host=SERVER_IP, port=port, db=TEST[0]) else: self.client = redis.StrictRedis(host=SERVER_IP, port=port, db=LIVE[0]) def set_settings(self, name, data): """Init settings if db don't exist""" if not self.client.hexists('settings', name): self.client.hset('settings', name, json.dumps(data)) return True return False def edit_setting(self, name, data): """Edit an entry in settings""" if self.client.hexists('settings', name): self.client.hset('settings', name, json.dumps(data)) return True return False def delete_setting(self, name): """Delete an entry in settings""" return self.client.hdel('settings', name) def get_setting(self, name): """Get an entry in settings""" setting = self.client.hget('settings', name) return json.loads(setting) if setting else None def get_all_settings(self): """Get all entries in settings""" settings = self.client.hgetall('settings') return {k.decode(): json.loads(v) for k, v in settings.items()}

    Und hier die Initialisierung

    settings_data = PortfolioSettings() ##################### # Will only be executed if DB is not available! ##################### if not settings_data.get_all_settings(): # Settings initialisieren print("INIT") settings_data.set_settings("project", "Portfolio") settings_data.set_settings("version", "0.0.3") settings_data.set_settings("theme", "dark") settings_data.set_settings("url_list", ["https://www.onvista.de/aktien/Deutsche-Telekom-Aktie-DE0005557508"]) settings_data.set_settings("exchange_list", ['DKB','Smartbroker','BUX'])

    Teile der Klasse sind [KI-generiert]

    Ich war zufrieden und habe die Klasse dann in mein Projekt übernommen und den Code überall entsprechend angepasst.

  • 0 Stimmen
    1 Beiträge
    2k Aufrufe
    Niemand hat geantwortet
  • Redis - Zweite Instanz

    Redis
    1
    0 Stimmen
    1 Beiträge
    167 Aufrufe
    Niemand hat geantwortet
  • 2,5G

    Linux
    2
    0 Stimmen
    2 Beiträge
    126 Aufrufe
    FrankMF

    Gutes Video zum Zyxel Switch, was ich vorher gar nicht kannte. Hätte meine Entscheidung aber auch nicht verändert.

  • 0 Stimmen
    1 Beiträge
    158 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    631 Aufrufe
    FrankMF

    So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands.

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

  • Raid1 - Platte verschwunden!?

    Verschoben Linux
    1
    1 Stimmen
    1 Beiträge
    394 Aufrufe
    Niemand hat geantwortet