Kopan replikayı onar: 1062 / 1032 satır çakışması

Komut

-- 1) Hatali worker, hata ve GTID
SELECT WORKER_ID, LAST_ERROR_NUMBER, LEFT(LAST_ERROR_MESSAGE, 250) AS last_error, APPLYING_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker
WHERE LAST_ERROR_NUMBER <> 0;

-- 2) Shell: relay log'da o transaction'in row image'larini coz
mysqlbinlog --base64-output=DECODE-ROWS -vv --include-gtids='af6bc361-c353-11f1-8f12-f69e63ad6c0e:11' /var/lib/mysql/db2-relay-bin.0* | grep '^###'

-- 3a) 1062 Duplicate entry: replikadaki fazla satiri binlog'a yazmadan sil
SET SESSION sql_log_bin = 0;
DELETE FROM shop.orders WHERE id = 20001;
-- 3b) 1032 Can't find record: eksik satiri WHERE (before image) degerleriyle ekle
INSERT INTO shop.orders (id, cust, amount, note, created) VALUES (6, 6, 9.00, 'n6', '2026-10-08 20:09:44');
SET SESSION sql_log_bin = 1;

-- 4) Applier'i baslat ve dogrula
START REPLICA SQL_THREAD;
SELECT SERVICE_STATE, LAST_ERROR_NUMBER FROM performance_schema.replication_applier_status_by_coordinator;

Ne yapar?

Row-based replikasyonun en sık iki kırılmasını (1062 duplicate key, 1032 row not found) transaction'ı atlamadan, replikadaki satırı kaynağın beklediği hale getirerek düzeltir; veri tutarlılığı korunur.

Ne zaman kullanılır?

Replica_SQL_Running = No ve hata 1062 / 1032 olduğunda; GTID'yi boş transaction ile atlamak yerine kalıcı onarım için.

Dikkat

Replikadaki düzeltme mutlaka sql_log_bin=0 ile yapılmalı; aksi halde errant GTID oluşur ve failover'da sorun çıkarır. super_read_only=ON ise önce geçici kapat, iş bitince geri aç. Before image değerleri binlog_row_image=FULL varsayar; MINIMAL'de yalnız PK gelir, satırın kalanı kaynaktan okunmalıdır. Aynı tabloda tek çakışma genellikle daha fazlasının işaretidir; onarımdan sonra pt-table-checksum ile tabloyu kaynakla karşılaştır. Relay log yolu için: SELECT @@relay_log_basename;