Skocz do zawartości

Przeszukaj forum

Pokazywanie wyników dla tagów 'redis'.

  • Szukaj wg tagów

    Wpisz tagi, oddzielając przecinkami.
  • Szukaj wg autora

Typ zawartości


Forum

  • Hosting
    • Bezpieczeństwo
    • Hardware
    • Optymalizacja
    • Programowanie
    • Software
    • Systemy operacyjne
  • Pozostałe zagadnienia branżowe
    • Domeny
    • Promocja, marketing i SEO
    • Webmastering
    • Pozostałe
  • Oferty
    • Ogłoszenia
    • Opinie
    • Zapytania
    • Zlecenia
  • RootNode.pl
    • Z życia RootNode
    • Dyskusje i sugestie
  • Po godzinach
    • Giełda
    • Offtopic

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Rozpocznij

    Koniec


Ostatnia aktualizacja

  • Rozpocznij

    Koniec


Filtruj po ilości...

Data dołączenia

  • Rozpocznij

    Koniec


Grupa


O mnie


Imię


Firma/marka


Funkcja w firmie

Znaleziono 2 wyniki

  1. Dzień dobry, rozglądam się w imieniu klienta za gotowym, w pełni zarządzalnym przez kogoś serwerem. Typ (vps, dedyk inne) do uzgodnienia. Co oferta powinna zawierać: dysk: od 350GB w górę, oczywiście SSD, ram: od 16GB w górę, jakaś dobra, szybka, procesor: tutaj to nie wiem, dobry zarządzanie: wsparcie w konfiguracji, zmiana ustawień, reagowanie na błędy, aktualizacje php, sql. Czyli chyba wszystko co się zawiera w słowie "zarządzany", możliwość instalacji elasticsearch, możliwość instalacji Redis. Pewnie o czymś zapomniałem - będę uzgadniać z konkretnymi osobami z konkretną ofertą. A te proszę wysyłać na maila: biuro małpa ipslink kropka pl
  2. Klaster redisa postawiony, skonfigurowany - wszystko działa poprawnie jak należy. Sentinel przełącza również poprawnie rolę na master dla węzła klastra redis'a. Niedogodność powstaje jednak po stronie samego HAProxy (jego konfiguracji): frontend Redis bind 192.168.70.90:6379 name 192.168.70.90:6379 mode tcp log global timeout client 30000 default_backend Redis_back backend Redis_back mode tcp timeout connect 30000 timeout server 30000 retries 3 option tcp-check tcp-check connect tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK server redis1 192.168.70.91:6379 check inter 1000 maxconn 1024 server redis2 192.168.70.92:6379 check inter 1000 maxconn 1024 server redis3 192.168.70.93:6379 check inter 1000 maxconn 1024 Zgodnie z powyższym, jeśli dany węzeł klastra redis'owego jest w stanie "role:slave" to HAProxy zgłasza go jako DOWN w swoich statystykach, co jest nieprawdą. Ktoś próbował tak ustawić konfigurację w HAProxy, aby węzły klastra redis'a w stanie "slave" były oznaczane jako BACKUP? Można w konfiguracji HAProxy użyć tcp-check expect rstring role:(master|slave) lecz to spowoduje, że ruch będzie przesyłany również i do tych węzłów, które będą jako slave, a to jest niedopuszczalne.
×
×
  • Utwórz nowe...

Ważne informacje

Korzystając z forum, wyrażasz zgodę na: Warunki korzystania z serwisu, Regulamin, Polityka prywatności.