Am configurat 2 servere keydb cu Active Replica, așa cum este descris aici: https://docs.keydb.dev/docs/active-rep/
Folosim HAproxy pentru a redirecționa traficul către serverul corect. Deci avem situația actuală:
keydb 001 - 10.0.0.7
keydb 002 - 10.0.0.8
Vrem să actualizăm și să repornim keydb 01.L-am pus în întreținere în HAproxy și toate conexiunile sunt drenate. Deci, serverul nu mai este folosit și toate conexiunile live vor fi direcționate către keydb 02.
Acum, când keydb 01 revine din nou, îi cere keydb 02 o sincronizare completă a db. După ce se face acest lucru, vedem că keydb 02 solicită și o sincronizare completă a db de la keydb 01!!! Acest lucru face ca keydb 02 să intre într-o stare de ÎNCĂRCARE, în timp ce este singurul server live din Haproxy.
Deci rezultatul este că există pentru o perioadă scurtă de timp, Niciun server keydb nu este live. Acest lucru are ca rezultat erori precum: ÎNCĂRCARE Redis încarcă setul de date în memorie
Întreaga idee a acestei configurații de replica activă este că este robustă, sigură și creează o configurație de înaltă disponibilitate. Cu toate acestea, în această situație înseamnă că de fiecare dată când un server este gata, se creează un scurt moment de nefuncționare completă. Acest lucru este inacceptabil pentru configurația noastră.
facem greșit? Este asta prin design? Sau trebuie să reconfiguram ceva?
Am testat cu sincronizări pe disc și fără disc. Nu este nici o diferență. Configurarea noastră (dintr-un manual ansible, astfel încât formatarea poate arăta puțin ciudată):
bind: „127.0.0.1 {{ my_private_ips[inventory_hostname] }}”
requirepass: „{{ keydb_auth }}”
masterauth: „{{ keydb_auth }}”
replicaof: "xxx 6379"
client-output-buffer-limit:
- normal 0 0 0
- replica 1024mb 256mb 60
- pubsub 32mb 8mb 60
repl-diskless-sync: da
port: 6379
memorie maxima: 3000m
active-replica: da
Executăm Ubuntu 20.04.2 LTS cu versiunea keydb 6.0.16.
Aici este fișierul jurnal keydb de la keydb 01, care se oprește pentru întreținere și revine din nou.
3812319:1439:C 18 iunie 2021 09:08:36.048 * DB salvat pe disc
3812319:1439:C 18 iunie 2021 09:08:36.054 * RDB: 3 MB de memorie utilizată de copiere la scriere
958:1439:S 18 iunie 2021 09:08:36.094 * Salvarea în fundal sa încheiat cu succes
958:signal-handler (1624000133) S-a primit oprirea programării SIGTERM...
958:signal-handler (1624000133) S-a primit oprirea programării SIGTERM...
958:1439:S 18 iunie 2021 09:08:53.194 # Închidere solicitată de utilizator...
958:1439:S 18 iunie 2021 09:08:53.194 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
958:1439:S 18 iunie 2021 09:08:53.194 * Salvarea instantaneului RDB final înainte de a ieși.
958:1439:S 18 iunie 2021 09:08:53.194 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
958:1439:S 18 iunie 2021 09:08:54.159 * DB salvat pe disc
958:1439:S 18 iunie 2021 09:08:54.159 * Eliminarea fișierului pid.
958:1439:S 18 iunie 2021 09:08:54.159 # KeyDB este acum gata să iasă, la revedere...
874:874:C 18 iunie 2021 09:09:04.528 * Înainte de a mă transforma într-o replică, folosind propriii parametri master pentru a sintetiza un master în cache: s-ar putea să mă sincronizez cu noul master doar cu un transfer parțial.
874:874:C 18 iunie 2021 09:09:04.531 * Observație: „active-replica da” implică „replica-read-only no”
874:874:C 18 iunie 2021 09:09:04.531 # oO0OoO0OoO0Oo KeyDB începe oO0OoO0OoO0Oo
874:874:C 18 iunie 2021 09:09:04.531 # Versiunea KeyDB=6.0.16, biți=64, commit=00000000, modificat=0, pid=874, tocmai a început
874:874:C 18 iunie 2021 09:09:04.531 # Configurație încărcată
874:874:C 18 iunie 2021 09:09:04.531 # AVERTISMENT supravegheat de systemd - TREBUIE să setați valori adecvate pentru TimeoutStartSec și TimeoutStopSec în unitatea dvs. de service.
874:874:C 18 iunie 2021 09:09:04.531 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
KeyDB 6.0.16 (00000000/0) pe 64 de biți
Rulează în modul de sine stătător
Port: 6379
PID: 957
Alăturați-vă comunității KeyDB! https://community.keydb.dev/
957:874:S 18 iunie 2021 09:09:04.781 # Server inițializat
957:874:S 18 iunie 2021 09:09:04.781 # AVERTISMENT overcommit_memory este setat la 0! Salvarea în fundal poate eșua în condiții de memorie scăzută.Pentru a remedia această problemă, adăugați „vm.overcommit_memory = 1” la /etc/sysctl.conf și apoi reporniți sau rulați comanda „sysctl vm.overcommit_memory=1” pentru ca aceasta să aibă efect.
957:874:S 18 iunie 2021 09:09:04.781 # AVERTISMENT, aveți activat suportul Transparent Huge Pages (THP) în nucleul dvs. Acest lucru va crea probleme de latență și de utilizare a memoriei cu KeyDB. Pentru a remedia această problemă, rulați comanda „echo never > /sys/kernel/mm/transparent_hugepage/enabled” ca root și adăugați-o la /etc/rc.local pentru a păstra setarea după o repornire. KeyDB trebuie repornit după ce THP este dezactivat.
957:874:S 18 iunie 2021 09:09:04.789 * Se încarcă RDB produs de versiunea 6.0.16
957:874:S 18 iunie 2021 09:09:04.789 * RDB vârsta de 11 secunde
957:874:S 18 iunie 2021 09:09:04.789 * Utilizarea memoriei RDB la crearea 100,16 Mb
957:874:S 18 iunie 2021 09:09:05.563 * DB încărcat de pe disc: 0,778 secunde
957:874:S 18 iunie 2021 09:09:05.563 * Înainte de a mă transforma într-o replică, folosind propriii parametri master pentru a sintetiza un master în cache: s-ar putea să mă pot sincroniza cu noul master doar cu un transfer parțial.
957:874:S 18 iunie 2021 09:09:05.563 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
957:1345:S 18 iunie 2021 09:09:05.563 Subiectul 1 în viață.
957:1344:S 18 iunie 2021 09:09:05.564 Subiectul 0 în viață.
957:1344:S 18 iunie 2021 09:09:05.564 * Conectare la MASTER 10.0.0.8:6379
957:1344:S 18 iunie 2021 09:09:05.564 * Sincronizarea MASTER <-> REPLICA a început
957:1344:S 18 iunie 2021 09:09:05.566 * Conectarea fără blocare pentru SYNC a declanșat evenimentul.
957:1344:S 18 iunie 2021 09:09:05.567 * Maestrul a răspuns la PING, replicarea poate continua...
957:1344:S 18 iunie 2021 09:09:05.571 * Replica 10.0.0.8:6379 solicită sincronizare
957:1344:S 18 iunie 2021 09:09:05.571 * Resincronizare completă solicitată de replica 10.0.0.8:6379
957:1344:S 18 iunie 2021 09:09:05.571 * S-a creat un record de replicare, noile mele ID-uri de replicare sunt „60759691a4adca42cced2fd1895a470ab7b9eebb” și „00000000000000000000000000000000000000000000000000000
957:1344:S 18 iunie 2021 09:09:05.571 * Întârziere următorul BGSAVE pentru SYNC fără disc
957:1344:S 18 iunie 2021 09:09:05.573 * Resincronizarea parțială nu este posibilă (fără master în cache)
957:1344:S 18 iunie 2021 09:09:11.521 * Resincronizare completă de la master: 3eb1532df27d6815eea8a420c7c72b04e03618dc:516117186158
957:1344:S 18 iunie 2021 09:09:11.521 * Înlăturarea stării master memorate anterior în cache.
957:1344:S 18 iunie 2021 09:09:11.530 * Sincronizare MASTER <-> REPLICA: primirea RDB transmisă în flux de la master cu EOF pe disc
957:1344:S 18 iunie 2021 09:09:11.603 * Se pornește BGSAVE pentru SYNC cu țintă: socket-uri replici
957:1344:S 18 iunie 2021 09:09:11.606 * Transferul RDB de fundal a început de pid 2412
2412:1344:C 18 iunie 2021 09:09:12.488 * RDB: 1 MB de memorie utilizată de copiere la scriere
957:1344:S 18 iunie 2021 09:09:12.488 # Transfer rdb fără disc, citire terminată din conductă, 1 replici încă în curs.
957:1344:S 18 iunie 2021 09:09:12.507 * Transferul RDB de fundal s-a încheiat cu succes
957:1344:S 18 iunie 2021 09:09:12.507 * Transfer RDB transmis în flux cu replica 10.0.0.8:6379 (socket). Se așteaptă REPLCONF ACK de la slave pentru a activa streaming
957:1344:S 18 iunie 2021 09:09:12.872 * Sincronizarea cu replica 10.0.0.8:6379 a reușit
957:1344:S 18 iunie 2021 09:10:12.799 # Eroare I/O la încercarea de sincronizare cu MASTER: conexiune pierdută
957:1344:S 18 iunie 2021 09:10:13.429 * Conectare la MASTER 10.0.0.8:6379
957:1344:S 18 iunie 2021 09:10:13.429 * Sincronizarea MASTER <-> REPLICA a început
957:1344:S 18 iunie 2021 09:10:13.429 * Conectarea fără blocare pentru SYNC a declanșat evenimentul.
957:1344:S 18 iunie 2021 09:10:13.429 * Maestrul a răspuns la PING, replicarea poate continua...
957:1344:S 18 iunie 2021 09:10:13.430 * Resincronizarea parțială nu este posibilă (fără master în cache)
957:1344:S 18 iunie 2021 09:10:19.943 * Resincronizare completă de la master: 349f88c33a6dc9d67a3cb4d623727d9f1047033d:516121643991
957:1344:S 18 iunie 2021 09:10:19.952 * MASTER <-> REPLICA sync: primirea RDB transmisă în flux de la master cu EOF pe disc
957:1344:S 18 iunie 2021 09:10:20.856 * MASTER <-> REPLICA sync: se încarcă DB în memorie
957:1344:S 18 iunie 2021 09:10:20.856 * Se încarcă RDB produs de versiunea 6.0.16
957:1344:S 18 iunie 2021 09:10:20.856 * vârsta RDB 1 secundă
957:1344:S 18 iunie 2021 09:10:20.856 * Utilizarea memoriei RDB la crearea 102,08 Mb
957:1344:S 18 iunie 2021 09:10:21.431 * Sincronizare MASTER <-> REPLICA: Terminat cu succes
957:1344:S 18 iunie 2021 09:10:21.431 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
957:1344:S 18 iunie 2021 09:10:21.431 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
957:1344:S 18 iunie 2021 09:11:03.197 * 10000 de modificări în 60 de secunde. Economisire...
957:1344:S 18 iunie 2021 09:11:03.200 * Salvarea în fundal a început de pid 4845
4845:1344:C 18 iunie 2021 09:11:04.015 * DB salvat pe disc
4845:1344:C 18 iunie 2021 09:11:04.018 * RDB: 2 MB de memorie utilizată de copiere la scriere
957:1344:S 18 iunie 2021 09:11:04.104 * Salvarea în fundal sa încheiat cu succes
957:1344:S 18 iunie 2021 09:12:05.071 * 10000 de modificări în 60 de secunde. Economisire...
957:1344:S 18 iunie 2021 09:12:05.075 * Salvarea în fundal a început de pid 4870
4870:1344:C 18 iunie 2021 09:12:05.963 * DB salvat pe disc
Aici este jurnalul keydb 02. Acest server a rămas âupâ, dar a fost în scurt timp indisponibil:
960:1388:S 18 iunie 2021 09:08:29.066 * Salvarea în fundal a început de pid 3814844
3814844:1388:C 18 iunie 2021 09:08:29.896 * DB salvat pe disc
3814844:1388:C 18 iunie 2021 09:08:29.901 * RDB: 3 MB de memorie utilizată de copiere la scriere
960:1388:S 18 iunie 2021 09:08:29.974 * Salvarea în fundal sa încheiat cu succes
960:1388:S 18 iunie 2021 09:08:54.176 # S-a pierdut conexiunea cu masterul.
960:1388:S 18 iunie 2021 09:08:54.176 * Memorarea în cache a stării master deconectate.
960:1388:S 18 iunie 2021 09:08:54.177 # S-a pierdut conexiunea cu replica client ID #11.
960:1388:S 18 iunie 2021 09:08:54.957 * Conectare la MASTER 10.0.0.7:6379
960:1388:S 18 iunie 2021 09:08:54.957 * Sincronizarea MASTER <-> REPLICA a început
960:1388:S 18 iunie 2021 09:09:02.073 # Condiție de eroare pe soclu pentru SYNC: Resursa indisponibilă temporar
960:1388:S 18 iunie 2021 09:09:02.988 * Conectare la MASTER 10.0.0.7:6379
960:1388:S 18 iunie 2021 09:09:02.988 * Sincronizarea MASTER <-> REPLICA a început
960:1388:S 18 iunie 2021 09:09:02.988 # Condiție de eroare pe soclu pentru SYNC: Operație acum în curs
960:1388:S 18 iunie 2021 09:09:03.998 * Conectare la MASTER 10.0.0.7:6379
960:1388:S 18 iunie 2021 09:09:03.998 * Sincronizarea MASTER <-> REPLICA a început
960:1388:S 18 iunie 2021 09:09:03.999 * Conectarea fără blocare pentru SYNC a declanșat evenimentul.
960:1388:S 18 iunie 2021 09:09:04.068 * Maestrul a răspuns la PING, replicarea poate continua...
960:1388:S 18 iunie 2021 09:09:04.084 * Resincronizarea parțială nu este posibilă (fără master în cache)
960:1388:S 18 iunie 2021 09:09:04.087 * Replica 10.0.0.7:6379 solicită sincronizare
960:1388:S 18 iunie 2021 09:09:04.087 * Resincronizare completă solicitată de replica 10.0.0.7:6379
960:1388:S 18 iunie 2021 09:09:04.087 * Întârziere următorul BGSAVE pentru SYNC fără disc
960:1388:S 18 iunie 2021 09:09:10.035 * Se pornește BGSAVE pentru SYNC cu țintă: socket-uri replici
960:1388:S 18 iunie 2021 09:09:10.042 * Transferul RDB de fundal a început cu pid 3814859
960:1388:S 18 iunie 2021 09:09:10.117 * Resincronizare completă de la master: 640f9e48636076058722301cc52ea8a21bc8e450:453896462998
960:1388:S 18 iunie 2021 09:09:10.118 * Înlăturarea stării master memorate anterior în cache.
960:1388:S 18 iunie 2021 09:09:10.122 * MASTER <-> REPLICA sync: primirea RDB transmisă în flux de la master cu EOF pe disc
960:1388:S 18 iunie 2021 09:09:10.999 * MASTER <-> REPLICA sync: se încarcă DB în memorie
960:1388:S 18 iunie 2021 09:09:11.000 * Replica este pe cale să încarce fișierul RDB primit de la master, dar există un copil RDB în așteptare care rulează. Eliminarea procesului 3814859 și eliminarea fișierului său temporar pentru a evita orice cursă
3814859:signal-handler (1624000150) S-a primit SIGUSR1 în copil, ieșind acum.
960:1388:S 18 iunie 2021 09:09:11.000 * Se încarcă RDB produs de versiunea 6.0.16
960:1388:S 18 iunie 2021 09:09:11.000 * vârsta RDB 0 secunde
960:1388:S 18 iunie 2021 09:09:11.000 * Utilizarea memoriei RDB la crearea 95,02 Mb
960:1388:S 18 iunie 2021 09:09:11.018 # Transfer rdb fără disc, citire terminată din conductă, 1 replici încă în curs.
960:1388:S 18 iunie 2021 09:09:11.019 # Transfer de fundal încheiat de semnalul 10
960:1388:S 18 iunie 2021 09:09:11.019 * Transfer RDB transmis în flux cu replica 10.0.0.7:6379 (socket). Se așteaptă REPLCONF ACK de la slave pentru a activa streaming
960:1388:S 18 iunie 2021 09:09:11.386 * Sincronizare MASTER <-> REPLICA: finalizat cu succes
960:1388:S 18 iunie 2021 09:09:11.386 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
960:1388:S 18 iunie 2021 09:09:11.386 # supraveghere systemd solicitată, dar NOTIFY_SOCKET nu a fost găsit
960:1388:S 18 iunie 2021 09:09:30.096 * 10000 de modificări în 60 de secunde. Economisire...
960:1388:S 18 iunie 2021 09:09:30.101 * Salvarea în fundal a început de pid 3814875
3814875:1388:C 18 iunie 2021 09:09:30.970 * DB salvat pe disc
3814875:1388:C 18 iunie 2021 09:09:30.975 * RDB: 5 MB de memorie utilizată de copiere la scriere
960:1388:S 18 iunie 2021 09:09:31.022 * Salvarea în fundal sa încheiat cu succes
960:1388:S 18 iunie 2021 09:10:12.795 # Replică de deconectare expirată: 10.0.0.7:6379
960:1388:S 18 iunie 2021 09:10:12.795 # Conexiunea cu replica 10.0.0.7:6379 pierdută.
960:1389:S 18 iunie 2021 09:10:13.429 * Replica 10.0.0.7:6379 solicită sincronizare
960:1389:S 18 iunie 2021 09:10:13.429 * Resincronizare completă solicitată de replica 10.0.0.7:6379
960:1389:S 18 iunie 2021 09:10:13.429 * Întârziere următorul BGSAVE pentru SYNC fără disc
960:1388:S 18 iunie 2021 09:10:19.941 * Se pornește BGSAVE pentru SYNC cu țintă: socket-uri replici
960:1388:S 18 iunie 2021 09:10:19.948 * Transferul RDB de fundal a început cu pid 3815442
3815442:1388:C 18 iunie 2021 09:10:20.860 * RDB: 5 MB de memorie utilizată de copiere la scriere
960:1388:S 18 iunie 2021 09:10:20.860 # Transfer rdb fără disc, citire terminată din conductă, 1 replici încă în curs.
960:1388:S 18 iunie 2021 09:10:20.958 * Transferul RDB de fundal s-a încheiat cu succes
960:1388:S 18 iunie 2021 09:10:20.958 * Transfer RDB transmis în flux cu replica 10.0.0.7:6379 (socket). Se așteaptă REPLCONF ACK de la slave pentru a activa streaming
960:1389:S 18 iunie 2021 09:10:22.034 * Sincronizarea cu replica 10.0.0.7:6379 a reușit
960:1388:S 18 iunie 2021 09:10:32.013 * 10000 de modificări în 60 de secunde. Economisire...
960:1388:S 18 iunie 2021 09:10:32.018 * Salvarea în fundal a început de pid 3816278
3816278:1388:C 18 iunie 2021 09:10:32.845 * DB salvat pe disc
3816278:1388:C 18 iunie 2021 09:10:32.850 * RDB: 4 MB de memorie utilizată de copiere la scriere
960:1388:S 18 iunie 2021 09:10:32.921 * Salvarea în fundal sa încheiat cu succes
960:1388:S 18 iunie 2021 09:11:33.101 * 10000 de modificări în 60 de secunde. Economisire...
