Die Antwort von ChatGPT wie der Redis ConnectionPool funktioniert. Ein paar Dinge finde ich komisch.
https://chat.openai.com/share/b10fdadc-2c9b-404a-bc99-c883d110d6af
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 BeitragDamit 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.1Hier 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 XXXXXXXXXXXXNach den Änderungen den Dienst Redis kurz neustarten.
service redis restartDas war's.
Server 2 SLAVE
/etc/redis/redis.conf
Hier ist es nicht nötig eine IP-Adresse anzugeben.
bind 127.0.0.1 ::1Der 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 6379Hiermit 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 XXXXXXXXXXDas alles speichern und den Dienst neustarten.
service redis restartIn 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.rdbNachher
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.rdbVom 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 sentNachher
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 sentEr 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.rdbSlave
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.rdbUnd 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 sentFertig! 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 -
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 successSlave
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