{"id":20436,"date":"2026-08-08T08:33:07","date_gmt":"2026-08-08T06:33:07","guid":{"rendered":"https:\/\/webhosting.de\/redis-failover-hosting-systeme-robust\/"},"modified":"2026-08-08T08:33:07","modified_gmt":"2026-08-08T06:33:07","slug":"systemy-hostingu-z-funkcja-przelaczania-awaryjnego-redis-niezawodne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/redis-failover-hosting-systeme-robust\/","title":{"rendered":"Strategie prze\u0142\u0105czania awaryjnego Redis dla system\u00f3w hostingowych w \u015brodowisku produkcyjnym"},"content":{"rendered":"<p>Funkcja Redis Failover zapewnia dost\u0119pno\u015b\u0107 produkcyjnych system\u00f3w hostingowych w przypadku awarii w\u0119z\u0142\u00f3w poprzez automatyczne przenoszenie r\u00f3l g\u0142\u00f3wnych na instancje replikacyjne, co pozwala na utrzymanie sesji, pami\u0119ci podr\u0119cznych i kolejek. Planuj\u0119 w tym celu <strong>Replikacja<\/strong>, procedury przejmowania i monitorowanie w taki spos\u00f3b, aby prze\u0142\u0105czanie przebiega\u0142o szybko, w spos\u00f3b kontrolowany i powtarzalny.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<p>Poni\u017csze punkty pozwalaj\u0105 szybko zapozna\u0107 si\u0119 z tre\u015bci\u0105 artyku\u0142u.<\/p>\n<ul>\n  <li><strong>Replikacja<\/strong> plus Sentinel lub klaster do automatycznego przejmowania zada\u0144<\/li>\n  <li><strong>Sharding<\/strong> w celu skalowania i zapewnienia odporno\u015bci na awarie przy pracy z du\u017cymi zbiorami danych<\/li>\n  <li><strong>Kworum<\/strong> a limity czasu decyduj\u0105 o szybko\u015bci prze\u0142\u0105czania i bezpiecze\u0144stwie<\/li>\n  <li><strong>RPO\/RTO<\/strong> okre\u015bli\u0107 dopuszczalny poziom utraty danych oraz czas przywr\u00f3cenia dzia\u0142ania<\/li>\n  <li><strong>Monitoring<\/strong> a testy pozwalaj\u0105 wykry\u0107 s\u0142abe punkty, zanim dojdzie do sytuacji kryzysowej<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-redis-failover-9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dlaczego prze\u0142\u0105czanie awaryjne zapewnia dost\u0119pno\u015b\u0107<\/h2>\n\n<p>Bez odpowiedniej logiki prze\u0142\u0105czania pami\u0119\u0107 podr\u0119czna lub baza danych sesji szybko staj\u0105 si\u0119 w przypadku awarii w\u0105skim gard\u0142em, dlatego obliczam <strong>Prze\u0142\u0105czanie awaryjne<\/strong> jako pierwszy wym\u00f3g. Z g\u00f3ry ustalam, jak du\u017ca utrata danych jest dopuszczalna (RPO) oraz jak szybko us\u0142ugi musz\u0105 ponownie zacz\u0105\u0107 odpowiada\u0107 (RTO). Redis replikuje si\u0119 asynchronicznie, dlatego planuj\u0119 czasy buforowania, mechanizmy zabezpieczaj\u0105ce ograniczaj\u0105ce zapisy oraz jasn\u0105 procedur\u0119 prze\u0142\u0105czania awaryjnego. Biblioteki klienckie musz\u0105 rozumie\u0107 mechanizmy Sentinel lub klastra, w przeciwnym razie po\u0142\u0105czenie zostanie przerwane w nieodpowiednim momencie. Uwzgl\u0119dniam op\u00f3\u017anienia mi\u0119dzy strefami, aby decyzje kworum pozosta\u0142y bezpieczne, a czasy prze\u0142\u0105czania nie uleg\u0142y nadmiernemu wyd\u0142u\u017ceniu.<\/p>\n\n<h2>Metoda \u201eSingle-Primary\u201d z w\u0119z\u0142em stra\u017cniczym: kiedy to wystarczy<\/h2>\n\n<p>W przypadku kompaktowych konfiguracji cz\u0119sto stosuj\u0119 jeden w\u0119ze\u0142 g\u0142\u00f3wny i co najmniej jeden w\u0119ze\u0142 replikuj\u0105cy, monitorowane przez trzy instancje Sentinel, poniewa\u017c nieparzysta liczba zapobiega niepewnym decyzjom w <strong>Kworum<\/strong>. Sentinels traktuj\u0119 jak niezale\u017cnych stra\u017cnik\u00f3w: wykrywaj\u0105 awarie, wybieraj\u0105 now\u0105 instancj\u0119 g\u0142\u00f3wn\u0105 (Primary) w drodze g\u0142osowania wi\u0119kszo\u015bciowego i przekazuj\u0105 nowe punkty ko\u0144cowe klientom. Aby zapewni\u0107 niezawodno\u015b\u0107 tych decyzji, umieszczam procesy na oddzielnych hostach lub w oddzielnych strefach. Dbam o to, aby klienci znali punkty ko\u0144cowe Sentinel i ponownie \u0142\u0105czyli si\u0119 z nimi zgodnie ze strategi\u0105 \u201efallback\u201d. Osoby, kt\u00f3re chc\u0105 zag\u0142\u0119bi\u0107 si\u0119 w ten temat, znajd\u0105 praktyczne szczeg\u00f3\u0142y w <a href=\"https:\/\/webhosting.de\/pl\/redis-sentinel-wysoka-dostepnosc-konfiguracja-serwera-redis-stabilnosc\/\">Instrukcja obs\u0142ugi Redis Sentinel<\/a>, w kt\u00f3rej w przyst\u0119pny spos\u00f3b wyja\u015bniono konfiguracj\u0119 i potencjalne trudno\u015bci.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_failover_meeting_6724.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Klaster z partycjonowaniem: skalowalno\u015b\u0107 i niezawodno\u015b\u0107<\/h2>\n\n<p>Je\u015bli obci\u0105\u017cenie lub ilo\u015b\u0107 danych wzro\u015bnie, przejd\u0119 na Redis Cluster z funkcj\u0105 shardingu, poniewa\u017c kilka serwer\u00f3w g\u0142\u00f3wnych dzieli przestrzenie kluczy, a dla ka\u017cdego shardu dost\u0119pna jest jedna lub wi\u0119cej replik; w ten spos\u00f3b <strong>Dost\u0119pno\u015b\u0107<\/strong> nawet w przypadku utraty w\u0119z\u0142a. To podej\u015bcie rozprasza obci\u0105\u017cenia w newralgicznych punktach, oddziela obci\u0105\u017cenie pami\u0119ci od obci\u0105\u017cenia procesora, a jednocze\u015bnie zapewnia zintegrowane przej\u0119cie obs\u0142ugi dla ka\u017cdego obszaru slotu. Planuj\u0119 przy tym przydzia\u0142 slot\u00f3w oraz liczb\u0119 replik na ka\u017cdy fragment tak, aby uwzgl\u0119dni\u0107 obci\u0105\u017cenia zwi\u0105zane z odczytem oraz wymagania dotycz\u0105ce prze\u0142\u0105czania awaryjnego. Google Cloud i Redis.io zalecaj\u0105 co najmniej jedn\u0105 replik\u0119 na ka\u017cdy fragment; w \u015brodowiskach o du\u017cym nat\u0119\u017ceniu ruchu zazwyczaj wybieram dwie. Istotne znaczenie ma routing klient\u00f3w: tylko sterowniki obs\u0142uguj\u0105ce klastry rozpoznaj\u0105 migracje slot\u00f3w bez przerw w dzia\u0142aniu.<\/p>\n\n<h2>Op\u00f3\u017anienie prze\u0142\u0105czania awaryjnego, kworum i zachowanie klienta<\/h2>\n\n<p>Prze\u0142\u0105czanie nie mo\u017ce by\u0107 ani zbyt szybkie, ani zbyt powolne, dlatego staram si\u0119 zachowa\u0107 r\u00f3wnowag\u0119 <strong>Limity czasu<\/strong> oraz warto\u015bci kworum. Je\u015bli ustawi\u0119 zbyt w\u0105skie przedzia\u0142y czasowe, istnieje ryzyko b\u0142\u0119dnych prze\u0142\u0105cze\u0144 w przypadku kr\u00f3tkotrwa\u0142ych zak\u0142\u00f3ce\u0144 w sieci; je\u015bli ustawi\u0119 je zbyt szeroko, u\u017cytkownicy odczuj\u0105 zauwa\u017calne przerwy w dzia\u0142aniu. Sprawdzam, czy sterowniki poprawnie przetwarzaj\u0105 przekierowania (MOVED\/ASK), wykrywanie sentineli oraz aktualizacje DNS. Redis zaleca stosowanie wielu sentineli i konserwatywnych prog\u00f3w, aby niewielkie wahania nie powodowa\u0142y zmian przyw\u00f3dztwa. W aplikacjach wra\u017cliwych na op\u00f3\u017anienia testuj\u0119 gwa\u0142towne zmiany obci\u0105\u017cenia i utrat\u0119 pakiet\u00f3w, aby zmierzy\u0107 rzeczywiste czasy prze\u0142\u0105czania i dostosowa\u0107 op\u00f3\u017anienia klient\u00f3w.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-failover-hosting-systems-4837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zarz\u0105dzanie utrat\u0105 danych: RPO, AOF i repl-diskless<\/h2>\n\n<p>Poniewa\u017c Redis stosuje replikacj\u0119, najcz\u0119\u015bciej asynchroniczn\u0105, minimalizuj\u0119 potencjalne straty za pomoc\u0105 <strong>RPO<\/strong>-zasady i odpowiednia trwa\u0142o\u015b\u0107 danych. Dzi\u0119ki AOF (appendonly yes) i appendfsync everysec zapisuj\u0119 stany co kilka sekund, podczas gdy migawki RDB s\u0105 tworzone rzadziej, ale za to w bardziej kompaktowej formie. W przypadku obci\u0105\u017ce\u0144 wymagaj\u0105cych intensywnego zapisu ustawiam parametry `min-replicas-to-write` i `min-replicas-max-lag`, aby serwer g\u0142\u00f3wny zapisywa\u0142 dane tylko wtedy, gdy wystarczaj\u0105ca liczba replik jest aktualna. Oceniam ustawienie repl-diskless-sync oraz odpowiedni\u0105 warto\u015b\u0107 repl-backlog-size, aby ponowne po\u0142\u0105czenia przebiega\u0142y szybko i przyrostowo. Przed rozpocz\u0119ciem projektu okre\u015blam, kt\u00f3re dane mog\u0105 by\u0107 ulotne (mo\u017cliwe do odtworzenia), a kt\u00f3re musz\u0105 by\u0107 chronione transakcyjnie.<\/p>\n\n<h2>Tworzenie kopii zapasowych i przywracanie danych: co testuj\u0119<\/h2>\n\n<p>Prze\u0142\u0105czanie awaryjne nie zast\u0119puje <strong>Kopie zapasowe<\/strong>, dlatego regularnie tworz\u0119 kopie zapasowe i testuj\u0119 przywracanie danych na podstawie rzeczywistych kopii zapasowych. \u0106wicz\u0119 procedury ponownego uruchamiania: wy\u0142\u0105czam serwer g\u0142\u00f3wny, uruchamia si\u0119 replika, stary serwer g\u0142\u00f3wny wraca do dzia\u0142ania, role s\u0105 prawid\u0142owo przypisywane, a klienci ponownie si\u0119 \u0142\u0105cz\u0105 bez konieczno\u015bci r\u0119cznej interwencji. W tym celu dokumentuj\u0119 procedury operacyjne zawieraj\u0105ce jasne polecenia, \u015bcie\u017cki eskalacji i kryteria przerwania. W oknach serwisowych symuluj\u0119 r\u00f3wnie\u017c od\u0142\u0105czenie od sieci, aby oceni\u0107 ryzyko wyst\u0105pienia zjawiska \u201esplit-brain\u201d. Do \u0107wicze\u0144 do\u0142\u0105czam zdarzenia monitorowania i metryki, aby m\u00f3c dok\u0142adnie oceni\u0107 osie czasu i w\u0105skie gard\u0142a.<\/p>\n\n<h2>Topologia i rozmieszczenie: strefy, hosty, antyafinno\u015b\u0107<\/h2>\n\n<p>Umieszczam w\u0119z\u0142y danych i stra\u017cnik\u00f3w osobno, aby pojedyncza <strong>Dziedzina b\u0142\u0119d\u00f3w<\/strong> nigdy nie ulegaj\u0105 awarii wszystkie naraz. R\u00f3\u017cne strefy dost\u0119pno\u015bci zmniejszaj\u0105 ryzyko, \u017ce problemy z sieci\u0105 lub zasilaniem unieruchomi\u0105 jednocze\u015bnie wiele r\u00f3l. Regu\u0142y antyafinno\u015bciowe gwarantuj\u0105, \u017ce serwery g\u0142\u00f3wne i ich repliki nie znajd\u0105 si\u0119 na tym samym fizycznym ho\u015bcie. Aby zapobiec zjawisku \u201esplit-brain\u201d, zapewniam wi\u0119kszo\u015b\u0107 kworum i odmawiam dost\u0119pu do zapisu, je\u015bli dost\u0119pnych jest zbyt ma\u0142o replik. Podstawowe informacje na temat sp\u00f3jno\u015bci i system\u00f3w kworum mo\u017cna znale\u017a\u0107 w artykule po\u015bwi\u0119conym <a href=\"https:\/\/webhosting.de\/pl\/replikacja-bazy-danych-spojnosc-strategie-split-brain-failover\/\">Strategie podzielonego m\u00f3zgu<\/a>, kt\u00f3ry w przejrzysty spos\u00f3b przedstawia procesy decyzyjne.<\/p>\n\n<h2>Konfiguracja: Kluczowe prze\u0142\u0105czniki w procesie produkcyjnym<\/h2>\n\n<p>Niekt\u00f3re opcje serwera maj\u0105 wp\u0142yw na bezpiecze\u0144stwo, trwa\u0142o\u015b\u0107 danych oraz <strong>Op\u00f3\u017anienie<\/strong> ma kluczowe znaczenie, dlatego definiuj\u0119 standardy w zale\u017cno\u015bci od obci\u0105\u017cenia. Aby zapewni\u0107 bezpiecze\u0144stwo zapisu, stosuj\u0119 parametry `min-replicas-to-write` i `min-replicas-max-lag`, dostosowuj\u0105c je do op\u00f3\u017anienia replikacji. W celu zapewnienia trwa\u0142o\u015bci danych wybieram opcj\u0119 \u201eAOF everysec\u201d lub, jako uzupe\u0142nienie, migawki RDB w rozs\u0105dnych odst\u0119pach czasu. Aby zapewni\u0107 stabilno\u015b\u0107 sieci, ustawiam opcj\u0119 \u201etcp-keepalive\u201d oraz realistyczne warto\u015bci limit\u00f3w czasu; w klastrze dostosowuj\u0119 parametr \u201ecluster-node-timeout\u201d do op\u00f3\u017anienia w strefie. Poni\u017csza tabela przedstawia typowe opcje oraz moje kr\u00f3tkie zalecenia.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Cel\/zalecenie<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>tylko do do\u0142\u0105czania<\/strong> \/ appendfsync<\/td>\n      <td>W\u0142\u0105cz AOF; everysec zapewnia optymalny kompromis mi\u0119dzy trwa\u0142o\u015bci\u0105 a wp\u0142ywem obci\u0105\u017cenia pisania<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>min-replik-do-zapisania<\/strong><\/td>\n      <td>Zapisywanie danych tylko wtedy, gdy obecnych jest X replik; zapobiega utracie danych w przypadku awarii sieci<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>min-replicas-max-lag<\/strong><\/td>\n      <td>Maksymalne op\u00f3\u017anienie replikacji w sekundach; zapobiega powstawaniu nieaktualnych replik<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>rozmiar-zastrze\u017conych-replik<\/strong><\/td>\n      <td>Wystarczaj\u0105cy bufor na stopniowe ponowne synchronizacje; rozmiar dostosowany do szybko\u015bci zapisu<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>repl-diskless-sync<\/strong><\/td>\n      <td>Szybsza synchronizacja pocz\u0105tkowa bez plik\u00f3w tymczasowych przy wystarczaj\u0105cej przepustowo\u015bci sieci<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp-keepalive<\/strong><\/td>\n      <td>Wcze\u015bniejsze wykrywanie nieaktywnych po\u0142\u0105cze\u0144; dostosowanie warto\u015bci do sieci i zap\u00f3r sieciowych<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>timeout<\/strong> \/ limit-czasu-w\u0119z\u0142a-klastra<\/td>\n      <td>Powi\u0105zanie okien prze\u0142\u0105czania i wykrywania z op\u00f3\u017anieniem i bud\u017cetem b\u0142\u0119d\u00f3w<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>limit bufora wyj\u015bciowego klienta<\/strong><\/td>\n      <td>Ograniczanie liczby klient\u00f3w z zaleg\u0142o\u015bciami; chroni serwer g\u0142\u00f3wny i repliki przed przeci\u0105\u017ceniem pami\u0119ci<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Sentinel a Cluster: pomoc w podj\u0119ciu decyzji<\/h2>\n\n<p>Wybieram mi\u0119dzy Sentinel a Cluster w zale\u017cno\u015bci od ilo\u015bci danych, przepustowo\u015bci, profilu odczytu\/zapisu oraz wymaganej <strong>Tolerancja b\u0142\u0119d\u00f3w<\/strong>. Je\u015bli nie potrzebuj\u0119 skalowania poziomego przestrzeni kluczy, Sentinel zapewnia proste rozwi\u0105zanie z jednym serwerem g\u0142\u00f3wnym i replikami. Je\u015bli potrzebuj\u0119 wielu serwer\u00f3w g\u0142\u00f3wnych, podzia\u0142u na sloty i automatycznego routingu, stawiam na klaster. Migracj\u0119 z trybu autonomicznego do klastra planuj\u0119 z wyprzedzeniem, aby haszowanie kluczy i przydzielanie slot\u00f3w nie zaskoczy\u0142y mnie podczas pracy. Praktyczne por\u00f3wnanie przedstawia artyku\u0142 <a href=\"https:\/\/webhosting.de\/pl\/klaster-redis-a-tryb-autonomiczny-w-hostingu-internetowym-hosting-redis\/\">Klaster a tryb autonomiczny<\/a>, w kt\u00f3rym wyja\u015bniono mocne strony i ograniczenia obu podej\u015b\u0107.<\/p>\n\n<h2>Sprawdzenie w praktyce: monitorowanie i alarmy<\/h2>\n\n<p>\u015aledz\u0119 wska\u017aniki, kt\u00f3re bezpo\u015brednio wskazuj\u0105 na awarie, op\u00f3\u017anienia lub obci\u0105\u017cenie pami\u0119ci, poniewa\u017c monitorowanie ma decyduj\u0105ce znaczenie dla <strong>Czas reakcji<\/strong>. Nale\u017c\u0105 do nich: stan replikacji, op\u00f3\u017anienie, obci\u0105\u017cenie kolejki zaleg\u0142o\u015bci, liczba pe\u0142nych resynchronizacji, przerwania po\u0142\u0105cze\u0144, usuni\u0119cia danych oraz blokady spowodowane powolnymi poleceniami. Sentinele i mened\u017cer klastra musz\u0105 prawid\u0142owo zg\u0142asza\u0107 zdarzenia typu \u201eheartbeat\u201d i \u201ewahl\u201d, abym m\u00f3g\u0142 prze\u015bledzi\u0107 proces podejmowania decyzji. Na poziomie aplikacji rejestruj\u0119 kody b\u0142\u0119d\u00f3w Redis oraz op\u00f3\u017anienia P95\/P99, aby wcze\u015bnie wykrywa\u0107 problemy klient\u00f3w. Uruchamiam alarmy, zanim u\u017cytkownicy cokolwiek zauwa\u017c\u0105: na przyk\u0142ad w przypadku przekroczenia prog\u00f3w op\u00f3\u017anienia replikacji, spadku liczby dost\u0119pnych replik lub gwa\u0142townego wzrostu przekierowa\u0144 typu MOVED.<\/p>\n\n<h2>Konserwacja podczas pracy: aktualizacje typu \u201erolling update\u201d i planowane prze\u0142\u0105czenia<\/h2>\n<p>Prace planowe przeprowadzam tak, aby u\u017cytkownicy w miar\u0119 mo\u017cliwo\u015bci niczego nie zauwa\u017cyli. Przed aktualizacj\u0105 sprawdzam stan replikacji, poziom zaleg\u0142o\u015bci oraz bie\u017c\u0105c\u0105 aktywno\u015b\u0107 plik\u00f3w AOF\/RDB. W konfiguracjach Sentinel w razie potrzeby inicjuj\u0119 kontrolowane prze\u0142\u0105czenie, kieruj\u0119 klient\u00f3w na inny w\u0119ze\u0142, a nast\u0119pnie aktualizuj\u0119 odci\u0105\u017cony w\u0119ze\u0142. W klastrze korzystam z <em>wdzi\u0119czny<\/em> Prze\u0142\u0105czanie odbywa si\u0119 dla ka\u017cdego shardu z osobna, dzi\u0119ki czemu \u017cadne sloty nie pozostaj\u0105 bez obsady. Blokuj\u0105ce operacje przepisywania AOF lub czasoch\u0142onne zadania zapisywania w tle planuj\u0119 poza oknami prze\u0142\u0105czania, aby unikn\u0105\u0107 niepotrzebnych skok\u00f3w op\u00f3\u017anie\u0144. Wa\u017cne jest zdefiniowane cofni\u0119cie zmian: je\u015bli po aktualizacji jaki\u015b w\u0119ze\u0142 nie mo\u017ce poprawnie uczestniczy\u0107 w procesie, cofam zmian\u0119, zanim przejd\u0119 do kolejnego w\u0119z\u0142a.<\/p>\n<p>W przypadku wdro\u017ce\u0144 bez przestoj\u00f3w stopniowo wy\u0142\u0105czam w\u0119z\u0142y aplikacji, opr\u00f3\u017cniam pule po\u0142\u0105cze\u0144, ustawiam kr\u00f3tkie czasy ponownych pr\u00f3b i wahania oraz sprawdzam, czy po prze\u0142\u0105czeniu na stary serwer g\u0142\u00f3wny nie pozosta\u0142y \u017cadne \u015bcie\u017cki zapisu. W szczeg\u00f3lnie wra\u017cliwych \u015brodowiskach przed prze\u0142\u0105czeniem tymczasowo zwi\u0119kszam bufor replikacji i ustalam bardziej konserwatywne limity czasu, aby unikn\u0105\u0107 b\u0142\u0119d\u00f3w prze\u0142\u0105czenia w trakcie okresu konserwacji.<\/p>\n\n<h2>Dzia\u0142anie w kontenerach i Kubernetes<\/h2>\n<p>Koordynacja kontener\u00f3w u\u0142atwia wdra\u017canie, ale wymaga dodatkowej staranno\u015bci. Stosuj\u0119 StatefulSets w celu zapewnienia stabilnych to\u017csamo\u015bci, zapisuj\u0119 metadane klastra oraz pliki AOF\/RDB na niezawodnych woluminach oraz definiuj\u0119 antyafinno\u015b\u0107, aby instancje g\u0142\u00f3wne i repliki nie znajdowa\u0142y si\u0119 na tym samym w\u0119\u017ale. Sondy gotowo\u015bci (Readiness) i aktywno\u015bci (Liveness) kalibruj\u0119 w taki spos\u00f3b, aby kr\u00f3tkotrwa\u0142e zatory nie prowadzi\u0142y od razu do ponownych uruchomie\u0144, a tym samym nie wywo\u0142ywa\u0142y kaskadowych prze\u0142\u0105cze\u0144 awaryjnych. PodDisruptionBudgets oraz uporz\u0105dkowane zako\u0144czenie dzia\u0142ania z wystarczaj\u0105cym okresem karencji zapobiegaj\u0105 niepo\u017c\u0105danej utracie wi\u0119kszo\u015bci podczas prac konserwacyjnych.<\/p>\n<p>W przypadku serwer\u00f3w Sentinel i komunikacji klastrowej planuj\u0119 wdro\u017cenie us\u0142ug bezinterfejsowych oraz stabilnych nazw host\u00f3w; upewniam si\u0119, \u017ce w przypadku zmian adres\u00f3w IP pliki konfiguracyjne pozostaj\u0105 aktualne i nie nadpisuj\u0105 starszych widok\u00f3w klastra po ponownym uruchomieniu. Zasady sieciowe ograniczaj\u0105 niezb\u0119dne porty do minimum, aby kana\u0142y steruj\u0105ce nie pozostawa\u0142y otwarte w sieci nak\u0142adkowej. W konfiguracjach wielostrefowych zapobiegam preempcji w przypadku w\u0119z\u0142\u00f3w wiod\u0105cych i zapewniam wystarczaj\u0105c\u0105 przepustowo\u015b\u0107, aby w razie awarii w\u0119z\u0142a pozosta\u0142o miejsce na ponowne rozmieszczenie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_failover_office_8423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bezpiecze\u0144stwo i wzmocnienie: ACL, TLS i izolacja<\/h2>\n<p>Dost\u0119pno\u015b\u0107 bez bezpiecze\u0144stwa jest zwodnicza. W\u0142\u0105czam uwierzytelnianie i korzystam z list ACL w Redis zamiast globalnych hase\u0142, przyznaj\u0119 tylko te uprawnienia, kt\u00f3re s\u0105 niezb\u0119dne dla danej roli, oraz oddzielam dost\u0119p do konserwacji od dost\u0119pu do aplikacji. Komunikacj\u0119 z w\u0119z\u0142ami danych, \u0142\u0105czami replikacyjnymi i us\u0142ugami monitoruj\u0105cymi zabezpieczam za pomoc\u0105 protoko\u0142u TLS; rotacja certyfikat\u00f3w i jasne zasady dotycz\u0105ce szyfrowania stanowi\u0105 cz\u0119\u015b\u0107 rutynowych czynno\u015bci konserwacyjnych. Tryb chroniony, restrykcyjne adresy wi\u0105zania oraz zapory sieciowe i zasady sieciowe uniemo\u017cliwiaj\u0105 uzyskanie dost\u0119pu przez nieautoryzowane sieci. W topologiach Sentinel stosuj\u0119 dedykowane dane logowania dla us\u0142ug stra\u017cniczych, aby zapewni\u0107 ich stabilno\u015b\u0107 nawet w przypadku zmian hase\u0142. Ograniczenia szybko\u015bci i limity bufor\u00f3w klienckich chroni\u0105 przed nadu\u017cyciami i niezamierzonymi skokami obci\u0105\u017cenia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_failover_strategien_3487.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sp\u00f3jno\u015b\u0107 w stosowaniu: wzorce i pu\u0142apki<\/h2>\n<p>W zale\u017cno\u015bci od konkretnego przypadku u\u017cycia decyduj\u0119, jaki poziom sp\u00f3jno\u015bci jest konieczny. Aby zapewni\u0107 wy\u017cszy poziom trwa\u0142o\u015bci, aplikacja mo\u017ce po wykonaniu krytycznych operacji zapisu czeka\u0107 na potwierdzenia z replik, akceptuj\u0105c w zamian niewielkie op\u00f3\u017anienia. Operacje odczytu z replik celowo oznaczam jako <em>prawdopodobnie sp\u00f3jne<\/em> i stosuj\u0119 je tylko tam, gdzie mo\u017cna zaakceptowa\u0107 nieaktualno\u015b\u0107 danych. Transakcje z WATCH\/MULTI\/EXEC oraz skrypty Lua dzia\u0142aj\u0105 atomowo na serwerze g\u0142\u00f3wnym; dlatego projektuj\u0119 polecenia tak, by by\u0142y idempotentne, co zapobiega powstawaniu podw\u00f3jnych efekt\u00f3w ubocznych w przypadku ponownej pr\u00f3by klienta po prze\u0142\u0105czeniu awaryjnym. Operacje blokuj\u0105ce (np. na listach lub strumieniach) wyposa\u017cam w sensowne limity czasu i mechanizmy cofania, aby podczas prze\u0142\u0105czania \u017cadne w\u0105tki nie blokowa\u0142y si\u0119 w niesko\u0144czono\u015b\u0107. W przypadku kolejek i strumieni zdarze\u0144 planuj\u0119 <em>przynajmniej raz<\/em>-semantyki i przeprowadzaj deduplikacj\u0119 po stronie odbiorcy, zamiast d\u0105\u017cy\u0107 do idealnej <em>dok\u0142adnie raz<\/em>-budowa\u0107 iluzje.<\/p>\n\n<h2>Model danych, ci\u015bnienie w zbiorniku i projekt kluczy<\/h2>\n<p>Solidne prze\u0142\u0105czanie awaryjne zaczyna si\u0119 od modelu danych. Unikam nadmiernie rozbudowanych kluczy i struktur monolitycznych, kt\u00f3re powoduj\u0105 d\u0142ugi czas replikacji lub zapisywania w pliku AOF, i dziel\u0119 je na \u0142atwe w zarz\u0105dzaniu segmenty. Sp\u00f3jnie ustalam warto\u015bci TTL, aby pami\u0119ci podr\u0119czne szybko si\u0119 \u201erozgrza\u0142y\u201d po prze\u0142\u0105czeniu, nie powoduj\u0105c efektu lawinowego. Wyb\u00f3r polityki usuwania danych oraz realistyczne ustawienie maxmemory zapobiegaj\u0105 wywo\u0142ywaniu nag\u0142ych fal usuwania danych przez szczytowe obci\u0105\u017cenia. Uwa\u017cnie monitoruj\u0119 fragmentacj\u0119 pami\u0119ci i operacje przepisywania w tle; w przypadku ograniczonych zasob\u00f3w nadaj\u0119 priorytet mechanizmom zapewniaj\u0105cym przewidywalne op\u00f3\u017anienia, nawet je\u015bli szczytowa przepustowo\u015b\u0107 nieco spadnie. W klastrach planuj\u0119 okna reshardingu i aktywnie r\u00f3wnowa\u017c\u0119 sloty, aby w og\u00f3le nie powstawa\u0142y punkty newralgiczne.<\/p>\n\n<h2>Pog\u0142\u0119bienie wiedzy na temat monitorowalno\u015bci: logi, \u015blady, SLO<\/h2>\n<p>Opr\u00f3cz wska\u017anik\u00f3w wykorzystuj\u0119 logi i zdarzenia jako o\u015b czasu: kiedy w\u0119ze\u0142 zosta\u0142 oznaczony jako nieaktywny, kiedy odby\u0142 si\u0119 wyb\u00f3r, kiedy nowy w\u0119ze\u0142 g\u0142\u00f3wny by\u0142 gotowy do zapisu? Agreguj\u0119 wpisy z dziennika Slowlog, oceniam anomalie za pomoc\u0105 narz\u0119dzia Latency Doctor i koreluj\u0119 je z metrykami systemowymi, takimi jak czas oczekiwania na operacje wej\u015bcia\/wyj\u015bcia (I\/O-Wait), przej\u0119cie czasu procesora (CPU-Steal) czy straty sieciowe. Dla us\u0142ugi definiuj\u0119 wska\u017aniki SLO (np. op\u00f3\u017anienie P99 i roczn\u0105 liczb\u0119 minut przestoju) oraz aktywnie monitoruj\u0119, czy prze\u0142\u0105czenia mieszcz\u0105 si\u0119 w bud\u017cecie b\u0142\u0119d\u00f3w. Syntetyczne kontrole przeprowadzane spoza domeny klastra wykrywaj\u0105 problemy z DNS lub zapor\u0105 sieciow\u0105, kt\u00f3rych nie wykrywaj\u0105 wewn\u0119trzne kontrole stanu.<\/p>\n\n<h2>Procedury testowe i \u0107wiczenia z symulacj\u0105 sytuacji kryzysowych<\/h2>\n<p>Nie testuj\u0119 wy\u0142\u0105cznie scenariuszy optymalnych. Do obowi\u0105zkowego programu nale\u017c\u0105: partycjonowanie sieci, uruchamianie \u201ena zimno\u201d w warunkach stresowych, awarie ca\u0142ych stref, przepe\u0142nione listy zada\u0144, w\u0119z\u0142y replikuj\u0105ce z powoln\u0105 lub wadliw\u0105 pami\u0119ci\u0105 oraz rozbie\u017cno\u015bci czasowe. Dokumentuj\u0119 oczekiwane reakcje i rzeczywiste wyniki pomiar\u00f3w, a nast\u0119pnie por\u00f3wnuj\u0119 je z warto\u015bciami RPO\/RTO. \u0106wiczenia symuluj\u0105ce chaos rozpoczynam na ma\u0142\u0105 skal\u0119, a nast\u0119pnie zwi\u0119kszam ich z\u0142o\u017cono\u015b\u0107 i czas trwania, a\u017c zespo\u0142y i systemy <em>na zasadzie pami\u0119ci mi\u0119\u015bniowej<\/em> reagowa\u0107. Wyniki tych dzia\u0142a\u0144 trafiaj\u0105 do podr\u0119cznik\u00f3w post\u0119powania, prog\u00f3w alarmowych i standardowych konfiguracji; tylko w ten spos\u00f3b testy staj\u0105 si\u0119 przejawem rzeczywistej odporno\u015bci, a nie jednorazowymi wydarzeniami.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/server-redis-strategie-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Koszty, bud\u017cet i planowanie zdolno\u015bci produkcyjnych<\/h2>\n<p>Odporno\u015b\u0107 ma swoj\u0105 cen\u0119 \u2013 w postaci dodatkowych w\u0119z\u0142\u00f3w, stref i trwa\u0142o\u015bci danych. Oszacowuj\u0119 koszt ka\u017cdej dodatkowej repliki i ka\u017cdej pomostowanej strefy, a nast\u0119pnie por\u00f3wnuj\u0119 go z korzy\u015bciami wynikaj\u0105cymi z kr\u00f3tszych warto\u015bci RTO\/RPO. Trwa\u0142o\u015b\u0107 z cz\u0119stymi synchronizacjami AOF zwi\u0119ksza niezawodno\u015b\u0107, ale podnosi koszty operacji wej\u015bcia\/wyj\u015bcia (I\/O) i op\u00f3\u017anienia; znajduj\u0119 punkt, w kt\u00f3rym potrzeby u\u017cytkownik\u00f3w i bud\u017cet s\u0105 ze sob\u0105 w harmonii. Wielko\u015bci zaleg\u0142o\u015bci, przepustowo\u015b\u0107 sieci dla synchronizacji repl-diskless oraz klasy pami\u0119ci masowej wybieram nie na podstawie przeczucia, lecz na podstawie zmierzonych szybko\u015bci zapisu i czas\u00f3w ponownej synchronizacji. W ten spos\u00f3b planowanie pojemno\u015bci staje si\u0119 ubezpieczeniem z jasn\u0105 polis\u0105, a nie buforem na wypadek nieprzewidzianych sytuacji.<\/p>\n\n<h2>Kr\u00f3tko m\u00f3wi\u0105c: tak planuj\u0119 prze\u0142\u0105czenie awaryjne Redis<\/h2>\n\n<p>Zaczynam od jasnego <strong>Cele<\/strong>: RPO, RTO, przewidywane obci\u0105\u017cenie, liczba stref i bud\u017cet. Ma\u0142e i \u015brednie konfiguracje otrzymuj\u0105 instancj\u0119 g\u0142\u00f3wn\u0105 (Primary), co najmniej jedn\u0105 replik\u0119 (Replica) oraz trzy instancje stra\u017cnicze (Sentinels) na oddzielnych hostach; wi\u0119ksze platformy konfiguruj\u0119 jako klastry z wieloma replikami na ka\u017cdy fragment (shard). Tworz\u0119 kopie zapasowe danych za pomoc\u0105 AOF lub dodatkowych migawek i regularnie przeprowadzam testy przywracania. Topologi\u0119, kworum i limity czasu dostosowuj\u0119 do op\u00f3\u017anie\u0144 sieciowych i bud\u017cetu b\u0142\u0119d\u00f3w, a sterowniki klienckie wybieram z obs\u0142ug\u0105 prze\u0142\u0105czania awaryjnego. Dzi\u0119ki temu Redis w codziennej eksploatacji pozostaje odporny na obci\u0105\u017cenia, szybki i przede wszystkim niezawodnie dost\u0119pny.<\/p>","protected":false},"excerpt":{"rendered":"<p>Prze\u0142\u0105czanie awaryjne Redis w produkcyjnych systemach hostingowych: replikacja, Sentinel, klastry i nadmiarowo\u015b\u0107 \u2013 zrozumia\u0142e wyja\u015bnienie.<\/p>","protected":false},"author":1,"featured_media":20429,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20436","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"172","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Failover","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20429","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20436","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=20436"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/20436\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/20429"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=20436"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=20436"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=20436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}