MariaDB Replikasyon Kurulumu: Primary, Replica ve GTID

Replikasyon nasıl çalışır?

Belgelerin özetine göre primary sunucuda veritabanına yapılan bütün güncellemeler (DML ve DDL) binary log'a olay olarak yazılır. Replika primary'ye bağlanır, bu olayları okur ve kendi tarafında uygular. Replikada okunan olaylar önce binary log ile aynı biçimdeki relay log dosyalarına yazılır; uygulama bu dosyalardan yapılır. Replika, primary'nin binary log'unda en son uyguladığı olayın konumunu hatırlar; bu sayede bağlantı kopsa da kaldığı yerden devam edebilir. Primary ile replikanın sürekli iletişimde olması gerekmez, sunucular bir süre çevrimdışı kalıp geri geldiğinde replikasyon devam eder.

Replikada iki temel iş parçacığı vardır. G/Ç (I/O) iş parçacığı primary'ye bağlanıp olayları relay log'a alır; SQL iş parçacığı relay log'daki olayları çalıştırır. Durum çıktısındaki Slave_IO_Running ve Slave_SQL_Running alanları tam olarak bu iki iş parçacığının durumunu gösterir. Belgeler replikasyonun okumaları birden çok sunucuya dağıtmak, ağır analizleri primary'den uzak tutmak, yedeği değişmeyen bir kopyadan almak ve veriyi yerel olarak dağıtmak için kullanıldığını sayar.

Terim notu: Belgeler tarihsel olarak 'master' ve 'slave' terimlerini kullanır ve MariaDB, geriye dönük uyumluluk için eski adları koruyarak 'primary' ve 'replica' eş anlamlılarını eklemektedir. Bu yüzden aynı yazıda START REPLICA ile START SLAVE, SHOW REPLICA STATUS ile SHOW SLAVE STATUS birlikte görürsünüz; ikisi de aynı işi yapar.

Sürüm uyumu

Belgelerin genel kuralı, replikanın primary ile aynı ya da daha yeni sürümde olmasıdır; bu kısıt küçük sürümler için de geçerlidir. Sürümler arası uyumluluk tablosuna göre MariaDB 12.3 replikası 10.6, 10.11, 11.4, 11.8 ve 12.3 primary'lerinden veri alabilir, ama 12.3 bir primary'yi 11.8 replikası izleyemez. Yükseltme yaparken önce replikaları, sonra primary'yi yükseltmeniz bu yüzdendir; ayrıntılar sürüm yükseltme yazısında. MariaDB 11.8'de varsayılan karakter setinin değiştiğini ve bunun eski replikalara (özellikle 10.6 ve öncesi) replikasyonu etkilediğini de belgeler ayrıca not eder.

1. Primary sunucuyu yapılandırmak

Primary'de dört şey gerekir: binary log açık olmalı, sunucunun benzersiz bir server_id değeri olmalı, günlük adları log-basename ile sabitlenmeli ve replikaların bağlanacağı bir kullanıcı bulunmalı. server_id 1 ile 2 üzeri 32 eksi 1 arasında bir sayıdır ve replikasyon grubundaki her sunucu için farklı olmalıdır. Belgeler log-basename verilmezse ana bilgisayar adının kullanıldığını ve bu ad değişirse sorun çıkacağını belirtir. Belgelerdeki örnek yapılandırma şöyledir; dosyaya ekledikten sonra sunucuyu yeniden başlatın:

[mariadb]
log-bin
server_id=1
log-basename=master1
binlog-format=mixed

Ardından replikanın kullanacağı hesap açılır. Bu hesaba yalnızca replikasyon yetkisi verilir:

CREATE USER 'replication_user'@'%' IDENTIFIED BY 'bigs3cret';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';

Örnekteki '%' her yerden bağlantıya izin verir; üretimde replikanın IP adresini yazmak daha güvenlidir (bkz. CREATE USER ve host kısmı). Belgeler iki ayarın replikasyonu bozabileceği konusunda uyarır: skip-networking=1 ise sunucu yalnızca yerel bağlantı kabul eder, bind-address 127.0.0.1 ise uzak replikalar bağlanamaz. Bu ayarlar ve güvenlik duvarı için uzaktan bağlantı ve bind-address ile UFW güvenlik duvarı yazılarına bakın.

2. Replikayı yapılandırmak

Replikanın da benzersiz bir server_id değeri olmalıdır ve bu değerin etkin olması için sunucunun yeniden başlatılması gerekir. Replikada binary log zorunlu değildir; ancak replikayı ileride primary yapmayı ya da ondan zincirleme başka bir replika beslemeyi düşünüyorsanız açmanız gerekir. Replikanın yanlışlıkla güncellenmesini önlemek için read_only değişkenini de burada ayarlamak yaygın bir düzendir (aşağıda ayrıntısı var).

[mariadb]
server_id=2
read_only=1

3. Başlangıç verisini taşımak

Replika boş bir sunucuyla başlarsa, primary'nin binary log'u en baştan elinizde olmadığı sürece veriyi kendisi tamamlayamaz. Bu yüzden önce primary'nin tutarlı bir kopyası replikaya yüklenir ve replikasyonun tam o kopyanın karşılık geldiği noktadan başlaması sağlanır. Belgeler, başlangıç noktası kopyanın anına tam uymazsa replikada eksik ya da çift işlem oluşabileceğini vurgular. Üç yol vardır.

Klasik yöntem: Primary'de FLUSH TABLES WITH READ LOCK ile tablolar kilitlenir ve bu oturum açık tutulur (oturum kapanırsa kilit kalkar). SHOW MASTER STATUS ile dosya adı ve konum not edilir, veri kopyalanır, kilit UNLOCK TABLES ile kaldırılır. Belgelere göre canlı sistemlerde kilidi yalnızca yerel kopya alınana kadar tutmanız yeterlidir; replikanın veriyi içe aktarmasını beklemenize gerek yoktur. Belgelerdeki çıktı örneği:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| master1-bin.000096 |      568 |              |                  |
+--------------------+----------+--------------+------------------+

UNLOCK TABLES;

mariadb-dump ile: Belgelere göre --master-data veya --dump-slave kullanıldığında GTID konumu döküm dosyasına yorum olarak eklenir. Bunlara --gtid eklenirse dosya, gtid_slave_pos ayarlayan ve CHANGE MASTER çalıştıran komutları da içerir. InnoDB tablolarında --single-transaction ile birlikte kullanmak, primary'yi uzun süre kilitlemeden tutarlı bir başlangıç sağlar.

mariadb-dump --all-databases --single-transaction --master-data=2 --gtid > /data/backup/replika_baslangic.sql

mariadb-backup ile: Büyük veritabanlarında fiziksel yedek daha hızlıdır. Yedek dizinindeki mariadb_backup_binlog_info dosyası binlog dosya adını, konumu ve GTID'yi verir. Ayrıntılar mariadb-backup yazısında.

4. CHANGE MASTER TO ile replikayı yönlendirmek

Veri yüklendikten sonra replikaya primary'nin adresini, kullanıcısını ve başlangıç noktasını söylersiniz. Klasik dosya adı ve konum yöntemiyle belgelerdeki örnek şöyledir; MASTER_LOG_FILE ve MASTER_LOG_POS değerleri yukarıdaki SHOW MASTER STATUS çıktısından gelir:

CHANGE MASTER TO
  MASTER_HOST='master.domain.com',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='bigs3cret',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master1-bin.000096',
  MASTER_LOG_POS=568,
  MASTER_CONNECT_RETRY=10;

Belgeler genel olarak GTID kullanılmasını önerir ve MariaDB 10.10'dan beri GTID varsayılan olarak kullanılır. GTID ile dosya adı ve konum yazmak yerine replikanın GTID konumunu ayarlar ve MASTER_USE_GTID=slave_pos dersiniz. Elinizde yalnızca dosya adı ve konum varsa, karşılık gelen GTID'yi yedeğin alındığı sunucuda BINLOG_GTID_POS() ile bulabilirsiniz:

SELECT BINLOG_GTID_POS("master-bin.000001", 600);

SET GLOBAL gtid_slave_pos = "0-1-2";
CHANGE MASTER TO
 master_host="127.0.0.1",
 master_port=3310,
 master_user="root",
 master_use_gtid=slave_pos;
START SLAVE;

Bu son örnek belgelerdeki GTID kurulum sayfasından alınmıştır ve test amaçlı yerel bir bağlantı kullanır; kendi kurulumunuzda root yerine yukarıda açtığınız replikasyon kullanıcısını ve MASTER_PASSWORD seçeneğini kullanın. Belgeler bir noktaya daha dikkat çeker: yedek mevcut bir replikadan alındıysa ve mysql.gtid_slave_pos tablosu tutarlı biçimde yedeklendiyse doğru GTID konumu zaten o tabloda bulunur ve ayrıca ayarlamanız gerekmez. Yedek primary'den alındıysa konum binary log'dadır ve elle ayarlanmalıdır.

5. Başlatmak ve durumu okumak

START REPLICA;
SHOW REPLICA STATUS \G

Belgelere göre replikasyon doğru çalışıyorsa çıktıda şu iki satır görünür:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

SHOW REPLICA STATUS, REPLICA MONITOR yetkisi ister ve sütunların sırası sürüme göre değişebilir; belgeler değeri sabit bir sıra numarası yerine alan adıyla okumayı önerir. MariaDB 11.6'dan itibaren aynı sütunlar INFORMATION_SCHEMA.SLAVE_STATUS tablosundan da sorgulanabilir. En sık bakacağınız alanlar:

Seconds_Behind_Master değerini yorumlarken dikkatli olun. Belgelere göre replika o an bir olay işlemiyorsa değer sıfırdır; seri replikada daha eski zaman damgalı işlemler değerin geriye gitmesine yol açabilir; replika yeniden başlatıldığında, durdurulmadan önce geride olsa bile ilk replike işlem başlayana kadar değer sıfır görünebilir (MDEV-17516). Ayrıca belgeler, SHOW PROCESSLIST içindeki TIME sütununun replikanın gecikmesini ölçmek için kullanılamayacağını, bunun için bu alana bakılması gerektiğini belirtir.

GTID neden önerilir?

GTID (Global Transaction ID), binary log'daki her olay grubuna eklenen ve bütün sunucularda aynı kalan bir kimliktir. Üç sayıdan oluşur, örneğin 0-1-10: ilk sayı alan kimliği (domain ID), ikincisi olay grubunun ilk yazıldığı sunucunun server_id değeri, üçüncüsü her olay grubunda artan sıra numarasıdır. Belgeler iki temel faydayı sayar. Birincisi, replikayı başka bir primary'ye yönlendirmek kolaylaşır: replika son uyguladığı GTID'yi hatırladığı için yeni primary'nin binlog'unda nereden devam edeceği bellidir; eski yöntemde ise eski primary'nin dosya adı ve konumundan yenisindeki karşılığı tahmin etmenin basit bir yolu yoktur. İkincisi, replikanın konumu mysql.gtid_slave_pos tablosunda, veri değişiklikleriyle aynı işlem içinde saklandığı için çökmeye dayanıklıdır.

Belgeler MariaDB ve MySQL'in GTID uygulamalarının birbiriyle uyumlu olmadığını da vurgular: MariaDB, MySQL primary'sinin replikası olabilir ama MySQL bir MariaDB primary'sinin replikası olamaz. MySQL'den geçiş planlıyorsanız MySQL'den MariaDB'ye geçiş yazısına bakın.

MASTER_USE_GTID üç değer alır: slave_pos, current_pos ve no. Belgeler slave_pos'u önerir; çünkü current_pos, replikada binlog'a yazılmış yerel işlemleri de konuma katar ve bu işlem primary'de olmadığı için bağlantı başarısız olabilir. Bir zamanlar primary olmuş bir sunucuyu replika yapmak için MASTER_DEMOTE_TO_SLAVE=1 seçeneği vardır; GTID konumunu gtid_current_pos değerinden başlatır. Replika GTID ile çalışırken yeni bir primary'ye geçmek yalnızca adresi değiştirmekten ibarettir:

STOP SLAVE;
CHANGE MASTER TO
 master_host='127.0.0.1',
 master_port=3312;
START SLAVE;

Belgeler primary değiştirirken sırayı da tarif eder: önce eski primary'ye yazma durdurulur, bütün değişikliklerin yeni primary'ye ulaşması beklenir, ancak ondan sonra yeni primary'ye yazılmaya başlanır. Aksi hâlde sunucuların binlog sıraları farklılaşır ve GTID tek bir noktayla durumu tarif edemez hâle gelir.

Replikayı salt okunur tutmak

Replikada yanlışlıkla yapılan bir güncelleme, primary'de olmayan bir değişiklik demektir ve ileride çakışmalara yol açar. Belgelere göre read_only=1 iken yalnızca READ ONLY ADMIN yetkisine sahip kullanıcılar ve primary'den gelen replikasyon güncellemeleri yazabilir; günlük tablolarına yazma ve geçici tablolardaki güncellemeler bu kısıttan muaftır. Replikada binary log açıksa ve gtid_strict_mode kullanılıyorsa, binlog'a giren her yerel değişiklik replikasyonu durdurur.

Replikada bakım için bir değişikliği gerçekten yapmanız gerekiyorsa ve bunun binlog'a girmesini istemiyorsanız, belgelerin önerdiği gibi oturumda sql_log_bin'i kapatın. Böylece değişiklik replikanın binlog'una yazılmaz ve diğer sunucuların GTID sırasını bozmaz.

SET sql_log_bin=0;
ALTER TABLE test ENGINE=rocksdb;

MariaDB 12.3 ile gelen kolaylıklar

Belgelere göre MariaDB 12.3'ten itibaren replikasyon bağlantı ayarları sunucu düzeyinde (seçenek dosyasında veya komut satırında) tanımlanıp kanallar arasında yeniden kullanılabilir. CHANGE MASTER TO içinde bir seçeneğe DEFAULT verildiğinde değer ilgili sunucu seçeneğinden alınır; bu destek MASTER_CONNECT_RETRY, MASTER_RETRY_COUNT, MASTER_HEARTBEAT_PERIOD, MASTER_USE_GTID ve bütün MASTER_SSL* seçeneklerini kapsar. DEFAULT olarak saklanan bir değer, sunucu seçeneği değiştiğinde (örneğin yeniden başlatmadan sonra) kendiliğinden güncellenir; açıkça verilen değerler ise sabit kalır. Belgelerdeki örnek:

master_ssl_ca   = /etc/mysql/ssl/ca.pem
master_ssl_cert = /etc/mysql/ssl/client-cert.pem
master_ssl_key  = /etc/mysql/ssl/client-key.pem
master_use_gtid = slave_pos

CHANGE MASTER 'primary_node_1' TO
  MASTER_HOST = '10.0.0.5',
  MASTER_SSL_CA = DEFAULT,
  MASTER_SSL_CERT = DEFAULT,
  MASTER_SSL_KEY = DEFAULT,
  MASTER_USE_GTID = DEFAULT;

START SLAVE 'primary_node_1';

Replikasyon trafiği ağdan geçtiği için şifrelenmesi önerilir. MASTER_SSL seçeneği 1 olmadıkça diğer MASTER_SSL* seçenekleri etkisizdir. Sunucu ve istemci tarafında TLS kurulumu SSL/TLS şifreli bağlantı yazısında. 12.3'ün diğer yenilikleri arasında SHOW BINLOG STATUS çıktısına eklenen Gtid_Binlog_Pos sütunu ve isteğe bağlı InnoDB tabanlı binary log sayılabilir; ikincisi replikaların GTID ile bağlanmasını zorunlu kılar ve önce replikaların 12.3'e yükseltilmesini ister. Ayrıntılar binary log ve MariaDB 12.3 yenilikleri yazılarında.

Uygulamalı özet: sıfırdan bir replika

Bütün adımları tek bir akışta toplayalım. Primary'de binary log ve server_id=1 açık, replikada server_id=2 ve read_only=1 var. Primary'de --master-data=2 --gtid --single-transaction ile bir döküm alınır ve replikaya taşınır. Replikada döküm yüklenir; dosyanın içindeki yorumlardan GTID konumu okunur, SET GLOBAL gtid_slave_pos ile ayarlanır, CHANGE MASTER TO ile primary'nin adresi, replikasyon kullanıcısı ve MASTER_USE_GTID=slave_pos verilir, START REPLICA çalıştırılır. Son olarak SHOW REPLICA STATUS \G ile iki iş parçacığının da Yes olduğu ve Last_IO_Error ile Last_SQL_Error alanlarının boş olduğu kontrol edilir. İlk çalıştırmadan sonra primary'de küçük bir test tablosu oluşturup replikada görünüp görünmediğine bakmak, kurulumun uçtan uca çalıştığını görmenin en kolay yoludur.

Sık yapılan hatalar

• Aynı server_id'yi iki sunucuda kullanmak: Belgeler değerin replikasyon grubundaki her sunucu için benzersiz olmasını şart koşar; replikada değişiklik için sunucuyu yeniden başlatmayı da unutmayın.
• log-basename vermemek: Günlük adları ana bilgisayar adına bağlı kalır ve makine adı değişince replikasyon sorun çıkarır.
• Primary'de bind-address 127.0.0.1 bırakmak: Belgelere göre bu durumda uzak replikaların bağlantısı başarısız olur.
• Kopya ile konum arasındaki uyumsuzluk: Kilit kalktıktan sonra not edilen bir konum, replikada eksik ya da çift işleme yol açar.
• Replikada doğrudan yazmak: Primary'de olmayan işlemler binlog sırasını bozar; read_only kullanın, bakımda sql_log_bin=0 yapın.
• Primary'yi replikadan önce yükseltmek: Replika primary ile aynı ya da daha yeni sürümde olmalıdır.
• Gecikmeyi SHOW PROCESSLIST ile ölçmek: TIME sütunu bunun için uygun değildir; Seconds_Behind_Master alanına bakın.

Sık Sorulan Sorular

Replikasyon bir yedek yerine geçer mi?

Hayır. Primary'de çalışan yanlış bir DELETE replikaya da aynen gider. Belgeler replikasyonu yedeklemeye yardımcı bir araç olarak anar: yedek, primary'yi yormadan replikadan alınabilir. Düzenli yedek ve binary log ile zamana göre kurtarma yine gereklidir.

Eski bir replikayı GTID kullanacak şekilde değiştirebilir miyim?

Evet. Belgelere göre dosya adı ve konumla bağlanan bir replika, GTID destekli bir primary'ye en az bir kez bağlandıysa GTID konumunu zaten izler. STOP SLAVE, ardından CHANGE MASTER TO master_use_gtid=slave_pos ve START SLAVE yeterlidir.

Replikasyon parolası değişti, ne yapmalıyım?

Belgelere göre CHANGE MASTER TO içinde belirtmediğiniz seçenekler çoğu durumda eski değerini korur; bu değerler varsayılan olarak master.info dosyasına (ya da master_info_file ile belirtilen dosyaya) yazılır. Yalnızca parola değiştiyse STOP SLAVE, ardından CHANGE MASTER TO MASTER_PASSWORD='yeni_parola' ve START SLAVE yeterlidir. MASTER_HOST veya MASTER_PORT değiştiğinde ise bazı seçenekler örtük olarak sıfırlanır.

Replikada SHOW REPLICA STATUS boş dönüyor, neden?

Replika için henüz CHANGE MASTER TO çalıştırılmamış olabilir. Çok kaynaklı (multi-source) replikasyonda ise bağlantı adı vermediğinizde default_master_connection değerindeki ad kullanılır; bütün bağlantıları görmek için SHOW ALL REPLICAS STATUS kullanılır.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · Binary log ve PITR · mariadb-dump ile yedekleme · mariadb-backup ile fiziksel yedek · SSL/TLS şifreli bağlantı · Uzaktan bağlantı ve bind-address