Changes between Initial Version and Version 1 of Replication

Timestamp:

11/26/25 16:39:30 (5 weeks ago)

Author:

222004

Comment:

--

Replication

@@ +1 @@
+
+== **Складирање и репликација**
+=== **Логичка репликација**
+\\
+Логичка репликација претставува процес на репродуцирање на податоците помеѓу повеќе јазли (инстанци) на база на податоци, при што промените направени на изворниот сервер се запишуваат во бинарни логови и потоа се репродуцираат на реплика-серверите.\\Во пракса, тоа претставува копирање на INSERT, UPDATE, DELETE и DDL операции од еден сервер кон друг, а не директно копирање на физичките датотеки.\\
+Овој метод овозможува систем отпорен на грешки (fault tolerant), бидејќи секоја промена што се случува на примарната база се пресликува и на репликите.\\
+ Дополнително, може да се користи за load-balancing - операции за читање се насочуваат кон реплика-инстанците, а write-операциите кон примарниот сервер,\\
+\\
+
+----
+
+=== **Подесување на MySQL GTID-базирана репликација со Docker**
+Во овој чекор ќе конфигурираме **GTID(Global Transaction Identifier)**-базирана логичка репликација во MySQL, користејќи две Docker инстанци  - **source и replica.**\\
+Секоја трансакција што се извршува во Source серверот добива GTID, кој обезбедува прецизно и автоматско следење и примена на промените во Replica.\\
+Во MySQL се користат бинарни log датотеки (binlog files) за да се запише секоја промена врз базата - **INSERT, UPDATE, DELETE и DDL**.\\
+//
+GTID структурата се гледа преку binlog, пример:\\
+
+{{{
+
+SET @@SESSION.GTID_NEXT='4e89b248–2c8e-11ed-af3b-020017000790:1';
+
+}}}
+\\
+Со **GTID** можеме да го користиме **AUTO_POSITION = 1**, што значи:\\
+> replica сама знае која трансакција ѝ недостига\\
+> не следиме BINLOG позиции рачно\\
+> можеме да рестартираме replica без губење на sync\\
+\\
+
+----
+
+==**Конфигурација на Source и Replica Docker инстанци**
+Се одлучивме за конфигурација преку Docker затоа што добиваме изолирана  и лесно пренослива средина, каде секоја MySQL инстанца е одвоена, конфигурирана со сопствени параметри и може да се стартува, стопира или реконфигурира без да влијае на остатокот од системот.\\
+===**Конфигурирање replica user**
+
+{{{
+
+CREATE USER IF NOT EXISTS 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'replpass';
+GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
+FLUSH PRIVILEGES;
+
+}}}
+
+Овој корисник е потребен за да се воспостави безбедна комуникација меѓу двата сервери. Привилегијата **REPLICATION SLAVE** дозволува читање на bin-log записите и нивно пренесување кон репликата, без да се доделуваат пошироки непотребни администраторски права.\\
+\\
+Во replica ја поставуваме врската кон изворниот MySQL инстанцa со следната команда:\\
+
+{{{
+
+CHANGE REPLICATION SOURCE TO
+  SOURCE_HOST = 'mysql_source',
+  SOURCE_PORT = 3306,
+  SOURCE_USER = 'repl',
+  SOURCE_PASSWORD = 'replpass',
+  SOURCE_AUTO_POSITION = 1;
+
+START REPLICA;
+
+}}}
+
+SQL-конфигурацијата ја одвоивме во посебни .sql фајлови кои автоматски се извршуваат преку docker-entrypoint, затоа што:\\
+> конфигурацијата станува репродуцибилна и повторно извршлива\\
+> setup-от на репликација е целосно автоматизиран (без рачно внесување команди)\\
+> ако се создадат контејнерите повторно, MySQL сам ќе ја примени истата конфигурација без дополнителна интервенција\\
+> документацијата, миграцијата и version-control стануваат чисти и управливи\\
+\\
+===Некои конфигурациски параметри за MySQL GTID-базирана репликација
+[[Image(mysql-parameters.png)]]
+
+За подигнување на GTID-базирана репликација, користиме docker-compose.yml во кој дефинираме две MySQL инстанци:\\
+>**source** → примарен сервер (прифаќа WRITE операции)\\
+>**replica** → сервер кој ги реплицира состојбите од source (READ-only)\\
+
+
+
+