docker

2026-02-17 21:17:42 +01:00
parent d90a6ed735
commit af57733506
17 changed files with 4194 additions and 59 deletions
@@ -0,0 +1,136 @@
+\section{Adatbázis replikáció}
+
+\begin{frame}{Mi az adatbázis replikáció?}
+  \begin{block}{Definíció}
+    Az adatok \textbf{több adatbázis példány között} vannak másolva annak érdekében,
+    hogy növekedjen a \textbf{rendelkezésre állás}, \textbf{skálázhatóság} és
+    \textbf{hibatűrés}.
+  \end{block}
+  \begin{itemize}
+    \item Primary–Replica (master–slave) felépítés a leggyakoribb
+    \item A replikáció lehet \textbf{szinkron} vagy \textbf{aszinkron}
+    \item Read-heavy alkalmazásoknál különösen hasznos
+  \end{itemize}
+\end{frame}
+
+\begin{frame}{Miért jó a replikáció?}
+  \begin{block}{Főbb előnyök}
+    \begin{itemize}
+      \item \textbf{Nagyobb rendelkezésre állás}: hiba esetén átváltás (failover)
+      \item \textbf{Skálázás olvasásra}: több replica olvasási terhelést visz el
+      \item \textbf{Biztonsági másolat}: adatvesztés kockázatának csökkentése
+      \item \textbf{Földrajzi közelség}: alacsonyabb késleltetés regionális replikákkal
+    \end{itemize}
+  \end{block}
+\end{frame}
+
+\begin{frame}{Replikációs topológiák}
+  \begin{itemize}
+    \item \textbf{Primary–Replica}: egy írható csomópont, több olvasó
+    \item \textbf{Multi-primary}: több írható csomópont (konfliktuskezelés szükséges)
+    \item \textbf{Chain/Cascade}: láncolt replikák nagy földrajzi területre
+  \end{itemize}
+  \begin{alertblock}{Gyakorlatban}
+    A legtöbb backend szolgáltatásnál a Primary–Replica modell az alapértelmezett.
+  \end{alertblock}
+\end{frame}
+
+\begin{frame}{Szinkron replikáció}
+  \begin{block}{Hogyan működik?}
+    \begin{itemize}
+      \item Az írás \textbf{csak akkor sikeres}, ha a replika is visszaigazolta
+      \item Erős \textbf{konzisztencia} (nincs adatvesztés írás után)
+      \item A primary \textbf{vár} a replikákra → nagyobb latency
+    \end{itemize}
+  \end{block}
+  \begin{exampleblock}{Mikor jó?}
+    Pénzügyi, tranzakciós rendszerek, ahol az adatvesztés nem elfogadható.
+  \end{exampleblock}
+\end{frame}
+
+\begin{frame}{Szinkron replikáció előnyök / hátrányok}
+  \begin{columns}
+    \begin{column}{0.48\textwidth}
+      \begin{block}{Előnyök}
+        \begin{itemize}
+          \item Erős konzisztencia
+          \item Minimális adatvesztés
+          \item Egyszerűbb olvasási modell
+        \end{itemize}
+      \end{block}
+    \end{column}
+    \begin{column}{0.48\textwidth}
+      \begin{alertblock}{Hátrányok}
+        \begin{itemize}
+          \item Nagyobb válaszidő írásnál
+          \item Érzékenyebb hálózati késleltetésre
+          \item Replikák kiesése lassítja az írást
+        \end{itemize}
+      \end{alertblock}
+    \end{column}
+  \end{columns}
+\end{frame}
+
+\begin{frame}{Aszinkron replikáció}
+  \begin{block}{Hogyan működik?}
+    \begin{itemize}
+      \item Az írás \textbf{azonnal sikeres}, a replika később frissül
+      \item Jobb \textbf{teljesítmény} és alacsonyabb latency
+      \item \textbf{Időbeli eltérés} lehetséges (eventual consistency)
+    \end{itemize}
+  \end{block}
+  \begin{exampleblock}{Mikor jó?}
+    Nagy forgalmú rendszerek, ahol az olvasási skálázás fontosabb, mint a tökéletes
+    konzisztencia (pl. hírportál, analytics).
+  \end{exampleblock}
+\end{frame}
+
+\begin{frame}{Aszinkron replikáció előnyök / hátrányok}
+  \begin{columns}
+    \begin{column}{0.48\textwidth}
+      \begin{block}{Előnyök}
+        \begin{itemize}
+          \item Alacsonyabb írási késleltetés
+          \item Jobb skálázhatóság
+          \item Replikák nem lassítják az írást
+        \end{itemize}
+      \end{block}
+    \end{column}
+    \begin{column}{0.48\textwidth}
+      \begin{alertblock}{Hátrányok}
+        \begin{itemize}
+          \item Ideiglenes inkonzisztencia
+          \item Failover esetén adatvesztés kockázata
+          \item Komplexebb olvasási logika
+        \end{itemize}
+      \end{alertblock}
+    \end{column}
+  \end{columns}
+\end{frame}
+
+\begin{frame}{Szinkron vs. aszinkron – döntési szempontok}
+  \begin{itemize}
+    \item \textbf{Konzisztencia igény}: kritikus adatok → szinkron
+    \item \textbf{Teljesítmény igény}: magas throughput → aszinkron
+    \item \textbf{Hálózat megbízhatósága}: nagy latency → aszinkron
+    \item \textbf{Üzleti kockázat}: adatvesztés megengedett? → aszinkron
+  \end{itemize}
+  \begin{alertblock}{Ökölszabály}
+    Ha az írások számítanak jobban, válaszd a szinkront. Ha az olvasási skálázás
+    és az alacsony latency fontos, válaszd az aszinkront.
+  \end{alertblock}
+\end{frame}
+
+\begin{frame}{Hogyan használjuk a gyakorlatban?}
+  \begin{block}{Tipikus architektúra}
+    \begin{itemize}
+      \item \textbf{Primary} kezeli az írásokat
+      \item \textbf{Replica} kiszolgálja az olvasásokat
+      \item \textbf{Load balancer} irányítja az olvasást a replikákhoz
+    \end{itemize}
+  \end{block}
+  \begin{exampleblock}{ORM/Prisma oldal}
+    A legtöbb ORM-ben (így Prismában is) külön connection stringet használsz az
+    író és az olvasó adatbázisokhoz, vagy read-replica routert konfigurálsz.
+  \end{exampleblock}
+\end{frame}