Mehmet

Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi
MySQL replication için bir sunucu source, diğer sunucu replica olarak yapılandırılır. Source üzerindeki işlemler binary log'a yazılır; replica bu kayıtları okuyup kendi relay log'una alır ve uygular. Yeni bir kurulumda dosya/konum takibi yerine GTID tabanlı replication kullanmak daha pratiktir. Aşağıdaki örnek, MySQL 8.4 kullanan, uygulama verisi bulunmayan iki yeni test sunucusu içindir. Mevcut bir source’a boş replica ekleme yöntemi değildir; o durumda tutarlı başlangıç kopyası ve GTID hazırlığı ayrıca gerekir.

1. Sunucuları hazırlayın​

İki MySQL sunucusunun TCP/IP üzerinden birbirine erişebildiğini ve 3306 portunun replica tarafından source'a ulaşılabilir olduğunu kontrol edin. Sunucuların server_id değerleri farklı olmalıdır. Örnekte source adresi db.example.com, source kimliği 1, replica kimliği 2 kabul edilmiştir.

Source sunucunun MySQL yapılandırmasına ekleyin:

Kod: 
[mysqld]
server-id=1
log-bin=source-bin
gtid-mode=ON
enforce-gtid-consistency=ON

Replica sunucunun yapılandırmasına ekleyin:

Kod: 
[mysqld]
server-id=2
relay-log=replica-relay-bin
super-read-only=ON
gtid-mode=ON
enforce-gtid-consistency=ON

Bu değişikliklerden sonra iki MySQL servisini yeniden başlatın. Source'ta binary log açık değilse replication çalışmaz. MySQL 8.4 için ROW satır biçimi varsayılandır. İki sunucunun server_uuid değerleri de farklı olmalıdır; veri dizinini körlemesine kopyalamayın. Mevcut üretim topolojisinde GTID modunu açmak, bu yeni test kurulumundan farklı bir geçiş planı gerektirir.

2. Source üzerinde replication kullanıcısı oluşturun​

Bu SQL'i source üzerinde çalıştırın. Kullanıcıya yalnızca replication için gereken yetki verilir:

Kod: 
CREATE USER 'repl'@'192.0.2.20'
  IDENTIFIED BY 'BENZERSIZ_GIZLI_PAROLA';

GRANT REPLICATION SLAVE ON *.*
  TO 'repl'@'192.0.2.20';

192.0.2.20 temsilî replica IP adresidir; source’un gördüğü gerçek bağlantı adresiyle değiştirin. Parola yer tutucusunu benzersiz bir gizli değerle değiştirin; örnek parolayı kullanmayın. Kullanıcı bilgileri replica'nın bağlantı metadata'sında tutulduğu için replication'a özel ayrı bir hesap kullanmak daha doğru olur.

3. Replica'yı source'a bağlayın​

Aşağıdaki SQL'i replica üzerinde çalıştırın. SOURCE_AUTO_POSITION=1, source ve replica'nın GTID setlerini karşılaştırarak gerekli işlemleri otomatik seçmesini sağlar; bu nedenle binary log dosyası ve pozisyonu yazılmaz.

Kod: 
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='db.example.com',
  SOURCE_PORT=3306,
  SOURCE_USER='repl',
  SOURCE_PASSWORD='BENZERSIZ_GIZLI_PAROLA',
  SOURCE_SSL=1,
  SOURCE_SSL_CA='/guvenli-yol/ca.pem',
  SOURCE_SSL_VERIFY_SERVER_CERT=1,
  SOURCE_AUTO_POSITION=1;

START REPLICA;
SHOW REPLICA STATUS\G

Bu örneğin ön koşulu source üzerinde TLS ve db.example.com adına uygun sunucu sertifikasıdır. Replica üzerinde güvenilen CA dosyası bulunmalıdır; örnek yolu gerçek dosyayla değiştirin. Doğrulama hatasında TLS kontrolünü kapatmak yerine sertifika adını, zincirini ve güven deposunu düzeltin.

4. Çalıştığını doğrulayın​

SHOW REPLICA STATUS\G çıktısında en az şu iki değer Yes olmalıdır:
AlanBeklenen değerAnlamı
Replica_IO_RunningYesReplica source'a bağlanıp binary log okuyor.
Replica_SQL_RunningYesOkunan işlemleri replica üzerinde uyguluyor.
Test için source üzerinde bir veritabanı ve kayıt oluşturun:

Kod: 
CREATE DATABASE repl_test;
USE repl_test;
CREATE TABLE mesaj (
  id INT PRIMARY KEY,
  icerik VARCHAR(100) NOT NULL
) ENGINE=InnoDB;
INSERT INTO mesaj VALUES (1, 'replication calisiyor');

Ardından replica üzerinde şu sorguyu çalıştırın:

Kod: 
SELECT * FROM repl_test.mesaj;

Satırın görünmesi bu test işleminin aktarıldığını gösterir; bütün verilerin tutarlılığını, failover hazırlığını veya sıfır veri kaybını garanti etmez. Kaynakta işlem yapıldığı halde replica'da görünmüyorsa önce SHOW REPLICA STATUS\G içindeki Last_IO_Error ve Last_SQL_Error alanlarını inceleyin.

Önemli kararlar ve yaygın hatalar​

  1. Replica'da source ile aynı başlangıç verisini kullanın. Mevcut ve farklı verilerle başlatmak, replication sırasında duplicate key veya eksik tablo hataları oluşturabilir.
  2. Her sunucuda farklı server-id kullanın. Aynı değer, source'un replica'ları ayırt edememesine yol açar.
  3. GTID kullanırken SOURCE_AUTO_POSITION=1 ile birlikte SOURCE_LOG_FILE ve SOURCE_LOG_POS vermeyin; bu iki yöntem aynı bağlantı tanımında karıştırılmamalıdır.
  4. Replica üzerinde uygulama yazmalarını sınırlandırın. Source'ta olmayan bir satırın replica'da oluşturulması veri çakışmasına ve SQL thread'in durmasına neden olabilir.
  5. Replication yedekleme değildir. Source'taki yanlış silme işlemi replica'ya da taşınabilir; ayrıca bağımsız yedek ve düzenli gecikme takibi gerekir.
Birden fazla source'tan tek replica'ya veri almak istiyorsanız her source için ayrı replication channel tanımlanır. Tek source → tek replica kurulumu için yukarıdaki tek kanallı yapı yeterlidir.

Sık sorulan sorular​

Seconds_Behind_Source sıfırsa veri kaybı olmayacağı kesin mi?​

Hayır. Bu alan tek başına uçtan uca gecikme veya bütünlük garantisi değildir. I/O ve uygulama durumunu, hata alanlarını ve alınan/uygulanan GTID kümelerini birlikte izleyin. Kaynağın kaybında hangi işlemlerin replica’ya ulaşmış olduğu ayrıca değerlendirilir.

GTID dosya konumu ve yedek ihtiyacını kaldırır mı?​

GTID auto-position işlem kimlikleriyle bağlantıyı konumlandırır; eksik başlangıç verisini yaratmaz ve silinmiş binary logları geri getirmez. Ayrı yedek, uygun log saklama ve tutarlı başlangıç kopyası gereksinimi devam eder.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Toplam: 0 (Üye: 0, misafir: 0, robot: 0)