Aracılığıyla paylaş

MySQL için Azure Veritabanı - Esnek Sunucuda çoğaltma gecikmesi sorunlarını giderme

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: MySQL için Azure Veritabanı - Tek Sunucu MySQL için Azure Veritabanı - Esnek Sunucu

Önemli

MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?

Not

Bu makalede, Microsoft'un artık kullanmadığını belirten bir terime başvuruda bulunur. Terim yazılımdan kaldırıldığında, bu makaleden kaldıracağız.

Okuma amaçlı çoğaltma özelliği, MySQL için Azure Veritabanı bir sunucudan salt okunur çoğaltma sunucusuna veri çoğaltmanıza olanak tanır. Okuma ve raporlama sorgularını uygulamadan çoğaltma sunucularına yönlendirerek iş yüklerinin ölçeğini genişletebilirsiniz. Bu kurulum, kaynak sunucu üzerindeki baskıyı azaltır ve ölçeklendirildikçe uygulamanın genel performansını ve gecikme süresini artırır.

Çoğaltmalar, MySQL altyapısının yerel ikili günlük (binlog) dosya konumu tabanlı çoğaltma teknolojisi kullanılarak zaman uyumsuz olarak güncelleştirilir. Daha fazla bilgi için bkz . MySQL binlog dosyası konum tabanlı çoğaltma yapılandırmasına genel bakış.

İkincil okuma çoğaltmalarında çoğaltma gecikmesi çeşitli faktörlere bağlıdır. Bu faktörler şunlardır ancak bunlarla sınırlı değildir:

  • Ağ gecikmesi.
  • Kaynak sunucudaki işlem birimi.
  • Kaynak sunucunun ve ikincil okuma amaçlı çoğaltma sunucusunun işlem katmanı.
  • Kaynak sunucuda ve ikincil sunucuda çalışan sorgular.

Bu makalede, MySQL için Azure Veritabanı çoğaltma gecikmesi sorunlarını gidermeyi öğreneceksiniz. Ayrıca, çoğaltma sunucularında artan çoğaltma gecikmesinin bazı yaygın nedenleri hakkında daha iyi bir fikir edineceksiniz.

Not

Bu makalede, Microsoft'un artık kullanmadığı köle terimi geçmektedir. Terim yazılımdan kaldırıldığında, bu makaleden kaldıracağız.

Çoğaltma kavramları

İkili günlük etkinleştirildiğinde, kaynak sunucu ikili günlüğe kaydedilmiş işlemler yazar. İkili günlük çoğaltma için kullanılır. 16 TB'a kadar depolamayı destekleyen yeni sağlanan tüm sunucular için varsayılan olarak açıktır. Çoğaltma sunucularında, her çoğaltma sunucusunda iki iş parçacığı çalışır. İş parçacıklarından biri GÇ iş parçacığı, diğeri ise SQL iş parçacığıdır:

  • GÇ iş parçacığı kaynak sunucuya bağlanır ve güncelleştirilmiş ikili günlükler istemektedir. Bu iş parçacığı ikili günlük güncelleştirmelerini alır. Bu güncelleştirmeler bir çoğaltma sunucusuna, geçiş günlüğü adlı yerel bir günlüğe kaydedilir.
  • SQL iş parçacığı geçiş günlüğünü okur ve ardından veri değişikliklerini çoğaltma sunucularına uygular.

Çoğaltma gecikme süresini izleme

MySQL için Azure Veritabanı saniye cinsinden çoğaltma gecikmesi için ölçümü sağlarAzure İzleyici. Bu ölçüm yalnızca okuma amaçlı çoğaltma sunucularında kullanılabilir. MySQL'de kullanılabilen seconds_behind_master ölçümüyle hesaplanır.

Artan çoğaltma gecikmesinin nedenini anlamak için MySQL Workbench veya Azure Cloud Shell kullanarak çoğaltma sunucusuna bağlanın. Ardından aşağıdaki komutu çalıştırın.

Not

Kodunuzda, örnek değerleri çoğaltma sunucusu adınız ve yönetici kullanıcı adınız ile değiştirin. Yönetici kullanıcı adı MySQL için Azure Veritabanı gerektirir@\<servername>.

mysql --host=myreplicademoserver.mysql.database.azure.com --user=myadmin@mydemoserver -p

Cloud Shell terminalinde deneyim şöyle görünür:

Requesting a Cloud Shell.Succeeded.
Connecting terminal...

Welcome to Azure Cloud Shell

Type "az" to use Azure CLI
Type "help" to learn about Cloud Shell

user@Azure:~$mysql -h myreplicademoserver.mysql.database.azure.com -u myadmin@mydemoserver -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 64796
Server version: 5.6.42.0 Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>

Aynı Cloud Shell terminalinde aşağıdaki komutu çalıştırın:

mysql> SHOW SLAVE STATUS;

İşte tipik bir çıkış:

Çoğaltma gecikme süresini izleme

Çıktı çok sayıda bilgi içerir. Normalde, yalnızca aşağıdaki tabloda açıklanan satırlara odaklanmanız gerekir.

Metrik Sistem Açıklama
Slave_IO_State GÇ iş parçacığının geçerli durumunu temsil eder. Normalde, kaynak (ana) sunucu eşitleniyorsa durum "Ana sunucunun olay göndermesi bekleniyor" olur. "Ana sunucuya bağlanılıyor" gibi bir durum, çoğaltmanın kaynak sunucuyla bağlantıyı kaybettiğini gösterir. Kaynak sunucunun çalıştığından emin olun veya güvenlik duvarının bağlantıyı engelleyip engellemediğini denetleyin.
Master_Log_File Kaynak sunucunun yazmakta olduğu ikili günlük dosyasını temsil eder.
Read_Master_Log_Pos Kaynak sunucunun ikili günlük dosyasında yazdığı yeri gösterir.
Relay_Master_Log_File Çoğaltma sunucusunun kaynak sunucudan okuduğu ikili günlük dosyasını temsil eder.
Slave_IO_Running GÇ iş parçacığının çalışıp çalışmadığını gösterir. Değer olmalıdır Yes. Değer ise NO, çoğaltma büyük olasılıkla bozuktur.
Slave_SQL_Running SQL iş parçacığının çalışıp çalışmadığını gösterir. Değer olmalıdır Yes. Değer ise NO, çoğaltma büyük olasılıkla bozuktur.
Exec_Master_Log_Pos Çoğaltmanın uyguladığı Relay_Master_Log_File konumunu gösterir. Gecikme süresi varsa, bu konum dizisi Read_Master_Log_Pos daha küçük olmalıdır.
Relay_Log_Space Tüm mevcut geçiş günlüğü dosyalarının toplam birleşik boyutunu gösterir. gibi relay_log_space_limitsorgular yaparak SHOW GLOBAL VARIABLES üst sınır boyutunu de kontrol edebilirsiniz.
Seconds_Behind_Master Çoğaltma gecikme süresini saniyeler içinde görüntüler.
Last_IO_Errno Varsa GÇ iş parçacığı hata kodunu görüntüler. Bu kodlar hakkında daha fazla bilgi için bkz . MySQL sunucusu hata iletisi başvurusu.
Last_IO_Error Varsa GÇ iş parçacığı hata iletisini görüntüler.
Last_SQL_Errno Varsa SQL iş parçacığı hata kodunu görüntüler. Bu kodlar hakkında daha fazla bilgi için bkz . MySQL sunucusu hata iletisi başvurusu.
Last_SQL_Error Varsa SQL iş parçacığı hata iletisini görüntüler.
Slave_SQL_Running_State Geçerli SQL iş parçacığı durumunu gösterir. Bu durumda, System lock normaldir. Durumunun da görülmesi normaldir Waiting for dependent transaction to commit. Bu durum, çoğaltmanın diğer SQL çalışan iş parçacıklarının kaydedilmiş işlemleri güncelleştirmesini beklediğini gösterir.

Slave_IO_Running Yes ve Slave_SQL_Running ise Yesçoğaltma sorunsuz çalışıyor demektir.

Ardından Last_IO_Errno, Last_IO_Error, Last_SQL_Errno ve Last_SQL_Error denetleyin. Bu alanlar, SQL iş parçacığının durmasına neden olan en son hatanın hata numarasını ve hata iletisini görüntüler. hata numarası 0 ve boş ileti, hata olmadığı anlamına gelir. MySQL sunucusu hata iletisi başvurusundaki hata kodunu denetleyerek sıfır olmayan hata değerlerini araştırın.

Yüksek çoğaltma gecikmesi için yaygın senaryolar

Aşağıdaki bölümlerde yüksek çoğaltma gecikme süresinin yaygın olduğu senaryolar ele alınıyor.

Kaynak sunucuda ağ gecikmesi veya yüksek CPU tüketimi

Aşağıdaki değerleri görürseniz çoğaltma gecikme süresi büyük olasılıkla kaynak sunucuda yüksek ağ gecikme süresi veya yüksek CPU tüketiminden kaynaklanır.

Slave_IO_State: Waiting for master to send event
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller than Master_Log_File, e.g. mysql-bin.00010

Bu durumda GÇ iş parçacığı çalışıyor ve kaynak sunucuda bekliyor. Kaynak sunucu zaten 20 numaralı ikili günlük dosyasına yazıldı. Çoğaltma yalnızca en fazla 10 dosya numarası aldı. Bu senaryoda yüksek çoğaltma gecikmesi için birincil faktörler, kaynak sunucuda ağ hızı veya yüksek CPU kullanımıdır.

Azure'da, bir bölge içindeki ağ gecikmesi genellikle milisaniye olarak ölçülebilir. Bölgeler arasında gecikme süresi milisaniyeden saniyeye kadar değişir.

Çoğu durumda, GÇ iş parçacıkları ile kaynak sunucu arasındaki bağlantı gecikmesi, kaynak sunucuda yüksek CPU kullanımından kaynaklanır. GÇ iş parçacıkları yavaş işlenir. Kaynak sunucudaki CPU kullanımını ve eşzamanlı bağlantı sayısını denetlemek için Azure İzleyici'yi kullanarak bu sorunu algılayabilirsiniz.

Kaynak sunucuda yüksek CPU kullanımı görmüyorsanız sorun ağ gecikmesi olabilir. Ağ gecikme süresi aniden anormal düzeyde yüksekse bilinen sorunlar veya kesintiler için Azure durum sayfasını gözden geçirin.

Kaynak sunucuda yoğun işlem artışları

Aşağıdaki değerleri görüyorsanız, kaynak sunucudaki yoğun işlem artışları büyük olasılıkla çoğaltma gecikmesine neden oluyordur.

Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller then Master_Log_File, e.g. mysql-bin.00010

Çıktı, çoğaltmanın kaynak sunucunun arkasındaki ikili günlüğü alabildiğini gösterir. Ancak çoğaltma GÇ iş parçacığı geçiş günlük alanının zaten dolu olduğunu gösterir.

Gecikmeye ağ hızı neden olmuyor. Çoğaltma yakalamaya çalışıyor. Ancak güncelleştirilmiş ikili günlük boyutu geçiş günlük alanının üst sınırını aşıyor.

Bu sorunu gidermek için kaynak sunucuda yavaş sorgu günlüğünü etkinleştirin. Kaynak sunucuda uzun süre çalışan işlemleri tanımlamak için yavaş sorgu günlüklerini kullanın. Ardından, sunucudaki gecikme süresini azaltmak için tanımlanan sorguları ayarlayın.

Bu sıralamanın çoğaltma gecikmesi genellikle kaynak sunucudaki veri yükünden kaynaklanır. Kaynak sunucularda haftalık veya aylık veri yükleri olduğunda çoğaltma gecikmesi ne yazık ki kaçınılmazdır. Çoğaltma sunucuları, kaynak sunucudaki veri yükü tamamlandıktan sonra sonunda yakalar.

Çoğaltma sunucusunda yavaşlık

Aşağıdaki değerleri gözlemlerseniz, sorun çoğaltma sunucusunda olabilir.

Slave_IO_State: Waiting for master to send event
Master_Log_File: The binary log file sequence equals to Relay_Master_Log_File, e.g. mysql-bin.000191
Read_Master_Log_Pos: The position of master server written to the above file is larger than Relay_Log_Pos, e.g. 103978138
Relay_Master_Log_File: mysql-bin.000191
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: The position of slave reads from master binary log file is smaller than Read_Master_Log_Pos, e.g. 13468882
Seconds_Behind_Master: There is latency and the value here is greater than 0

Bu senaryoda, çıktı hem GÇ iş parçacığının hem de SQL iş parçacığının düzgün çalıştığını gösterir. Çoğaltma, kaynak sunucunun yazdığı ikili günlük dosyasını okur. Ancak, çoğaltma sunucusundaki bazı gecikme süreleri kaynak sunucudan aynı işlemi yansıtır.

Aşağıdaki bölümlerde bu tür bir gecikme süresinin yaygın nedenleri açıklanmaktadır.

Tabloda birincil anahtar veya benzersiz anahtar yok

MySQL için Azure Veritabanı satır tabanlı çoğaltma kullanır. Kaynak sunucu ikili günlüğe olayları yazar ve değişiklikleri tek tek tablo satırlarına kaydeder. Ardından SQL iş parçacığı bu değişiklikleri çoğaltma sunucusundaki ilgili tablo satırlarına çoğaltır. Bir tabloda birincil anahtar veya benzersiz anahtar olmadığında, SQL iş parçacığı değişiklikleri uygulamak için hedef tablodaki tüm satırları tarar. Bu tarama çoğaltma gecikmesine yol açabilir.

MySQL'de birincil anahtar, NULL değerleri içeremediğinden hızlı sorgu performansı sağlayan ilişkili bir dizindir. InnoDB depolama altyapısını kullanıyorsanız, tablo verileri fiziksel olarak birincil anahtara göre ultra hızlı aramalar ve sıralamalar yapacak şekilde düzenlenir.

Çoğaltma sunucusunu oluşturmadan önce kaynak sunucudaki tablolara birincil anahtar eklemenizi öneririz. Kaynak sunucuya birincil anahtarlar ekleyin ve ardından çoğaltma gecikme süresini iyileştirmeye yardımcı olmak için okuma amaçlı çoğaltmaları yeniden oluşturun.

Kaynak sunucuda hangi tablolarda birincil anahtar eksik olduğunu bulmak için aşağıdaki sorguyu kullanın:

select tab.table_schema as database_name, tab.table_name 
from information_schema.tables tab left join 
information_schema.table_constraints tco 
on tab.table_schema = tco.table_schema 
and tab.table_name = tco.table_name 
and tco.constraint_type = 'PRIMARY KEY' 
where tco.constraint_type is null 
and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') 
and tab.table_type = 'BASE TABLE' 
order by tab.table_schema, tab.table_name;

Çoğaltma sunucusunda uzun süre çalışan sorgular

Çoğaltma sunucusundaki iş yükü, SQL iş parçacığının GÇ iş parçacığının arkasında gecikmesine neden olabilir. Çoğaltma sunucusunda uzun süre çalışan sorgular, yüksek çoğaltma gecikmesinin yaygın nedenlerinden biridir. Bu sorunu gidermek için çoğaltma sunucusunda yavaş sorgu günlüğünü etkinleştirin.

Yavaş sorgular kaynak tüketimini artırabilir veya çoğaltmanın kaynak sunucuya yetişememesi için sunucuyu yavaşlatabilir. Bu senaryoda yavaş sorguları ayarlayın. Daha hızlı sorgular SQL iş parçacığının engellenmesini önler ve çoğaltma gecikme süresini önemli ölçüde artırır.

Kaynak sunucuda DDL sorguları

Kaynak sunucuda, gibi ALTER TABLE bir veri tanımı dili (DDL) komutu uzun sürebilir. DDL komutu çalışırken, kaynak sunucuda diğer binlerce sorgu paralel olarak çalışıyor olabilir.

DDL çoğaltıldığında, veritabanı tutarlılığını sağlamak için MySQL altyapısı DDL'yi tek bir çoğaltma iş parçacığında çalıştırır. Bu görev sırasında, diğer tüm çoğaltılan sorgular engellenir ve çoğaltma sunucusunda DDL işlemi bitene kadar beklemesi gerekir. Bu gecikmeye çevrimiçi DDL işlemleri bile neden olur. DDL işlemleri çoğaltma gecikme süresini artırır.

Kaynak sunucuda yavaş sorgu günlüğünü etkinleştirdiyseniz, kaynak sunucuda çalıştırılan bir DDL komutunu denetleyerek bu gecikme sorununu algılayabilirsiniz. Dizin bırakma, yeniden adlandırma ve oluşturma yoluyla ALTER TABLE için INPLACE algoritmasını kullanabilirsiniz. Tablo verilerini kopyalamanız ve tabloyu yeniden oluşturmanız gerekebilir.

Genellikle INPLACE algoritması için eşzamanlı DML desteklenir. Ancak, işlemi hazırlayıp çalıştırdığınızda tabloda kısa bir süre özel meta veri kilidi alabilirsiniz. Bu nedenle CREATE INDEX deyimi için ALGORITHM ve LOCK yan tümcelerini kullanarak tablo kopyalama yöntemini ve okuma ve yazma için eşzamanlılık düzeyini etkileyebilirsiniz. Bir FULLTEXT dizini veya SPATIAL dizini ekleyerek DML işlemlerini engellemeye devam edebilirsiniz.

Aşağıdaki örnek, ALGORITHM ve LOCK yan tümcelerini kullanarak bir dizin oluşturur.

ALTER TABLE table_name ADD INDEX index_name (column), ALGORITHM=INPLACE, LOCK=NONE;

Ne yazık ki, kilit gerektiren bir DDL deyimi için çoğaltma gecikmesini önleyemezsiniz. Olası etkileri azaltmak için bu tür DDL işlemlerini örneğin gece saatlerinde yoğun olmayan saatlerde gerçekleştirin.

Düşürülen çoğaltma sunucusu

MySQL için Azure Veritabanı okuma amaçlı çoğaltmalar, kaynak sunucuyla aynı sunucu yapılandırmasını kullanır. Çoğaltma sunucusu yapılandırmasını oluşturulduktan sonra değiştirebilirsiniz.

Çoğaltma sunucusu düşürülirse, iş yükü daha fazla kaynak tüketebilir ve bu da çoğaltma gecikmesine neden olabilir. Bu sorunu algılamak için Azure İzleyici'yi kullanarak çoğaltma sunucusunun CPU ve bellek tüketimini denetleyin.

Bu senaryoda, çoğaltma sunucusunun yapılandırmasını kaynak sunucunun değerlerine eşit veya ondan büyük değerlerde tutmanızı öneririz. Bu yapılandırma, çoğaltmanın kaynak sunucuya ayak uydurmasını sağlar.

Kaynak sunucu parametrelerini ayarlayarak çoğaltma gecikme süresini iyileştirme

MySQL için Azure Veritabanı'da, çoğaltma varsayılan olarak çoğaltmalarda paralel iş parçacıklarıyla çalışacak şekilde iyileştirilmiştir. Kaynak sunucudaki yüksek eşzamanlılık iş yükleri çoğaltma sunucusunun geri düşmesine neden olduğunda, kaynak sunucuda binlog_group_commit_sync_delay parametresini yapılandırarak çoğaltma gecikme süresini geliştirebilirsiniz.

binlog_group_commit_sync_delay parametresi, ikili günlük dosyasını eşitlemeden önce ikili günlük işlemesinin kaç mikrosaniye beklediğini denetler. Bu parametrenin avantajı, işlenen her işlemi hemen uygulamak yerine kaynak sunucunun ikili günlük güncelleştirmelerini toplu olarak göndermesidir. Bu gecikme çoğaltmada GÇ'yi azaltır ve performansın geliştirilmesine yardımcı olur.

binlog_group_commit_sync_delay parametresini 1000 veya daha fazla olarak ayarlamak yararlı olabilir. Ardından çoğaltma gecikme süresini izleyin. Bu parametreyi dikkatli bir şekilde ayarlayın ve yalnızca yüksek eşzamanlılık iş yükleri için kullanın.

Önemli

Çoğaltma sunucusunda binlog_group_commit_sync_delay parametresinin 0 olması önerilir. Bu önerilir çünkü kaynak sunucudan farklı olarak, çoğaltma sunucusu yüksek eşzamanlılığa sahip olmaz ve çoğaltma sunucusundaki binlog_group_commit_sync_delay değerini artırmak istemeden çoğaltma gecikmesinin artmasına neden olabilir.

Birçok tek işlem içeren düşük eşzamanlılık iş yükleri için binlog_group_commit_sync_delay ayarı gecikme süresini artırabilir. GÇ iş parçacığı yalnızca birkaç işlem işleniyor olsa bile toplu ikili günlük güncelleştirmelerini beklediğinden gecikme süresi artabilir.

Gelişmiş Sorun Giderme Seçenekleri

Bağımlı durumu göster komutunun kullanılması çoğaltma gecikmesi sorunlarını gidermek için yeterli bilgi sağlamıyorsa, hangi işlemlerin etkin olduğunu veya beklediğini öğrenmek için bu ek seçenekleri görüntülemeyi deneyin.

İş parçacıkları tablosunu görüntüleme

Tabloda performance_schema.threads işlem durumu gösterilir. lock_type kilidi bekleniyor durumundaki bir işlem, tablolardan birinde bir kilit olduğunu ve çoğaltma iş parçacığının tabloyu güncelleştirmesini önlediğini gösterir.

SELECT name, processlist_state, processlist_time FROM performance_schema.threads WHERE name LIKE '%slave%';

Daha fazla bilgi için bkz . Genel İş Parçacığı Durumları.

replication_connection_status tablosunu görüntüleme

performance_schema.replication_connection_status tablosu, çoğaltmanın kaynakla bağlantısını işleyen çoğaltma G/Ç iş parçacığının geçerli durumunu gösterir ve daha sık değişir. Tablo, bağlantı sırasında değişen değerler içerir.

SELECT * FROM performance_schema.replication_connection_status;

replication_applier_status_by_worker tablosunu görüntüleme

Tabloda performance_schema.replication_applier_status_by_worker çalışan iş parçacıklarının durumu, Son görülen işlem ile son hata numarası ve ileti gösterilir. Bu durum, sorun yaşayan işlemi bulmanıza ve kök nedeni belirlemenize yardımcı olur.

Hataları veya işlemleri atlamak için Veri çoğaltmasında aşağıdaki komutları çalıştırabilirsiniz:

az_replication_skip_counter

veya

az_replication_skip_gtid_transaction

SELECT * FROM performance_schema.replication_applier_status_by_worker;

SHOW RELAYLOG EVENTS deyimini görüntüleme

deyimi, show relaylog events bir çoğaltmanın geçiş günlüğündeki olayları gösterir.

· GITD tabanlı çoğaltma (Okuma çoğaltması) için deyimi GTID işlemini ve binlog dosyasını ve konumunu gösterir; mysqlbinlog kullanarak çalıştırılan içerikleri ve deyimleri alabilirsiniz. · MySQL binlog konum çoğaltması için (Veri girişi çoğaltması için kullanılır), çalıştırılan deyimleri gösterir ve hangi tablo işlemlerinin çalıştırıldığını bilmenize yardımcı olur

InnoDB Standart İzleyici ve Kilit İzleyicisi Çıkışını Denetleme

Kilitleri ve kilitlenmeleri çözmeye ve çoğaltma gecikmesini en aza indirmeye yardımcı olmak için InnoDB Standart monitör ve Kilit İzleyicisi Çıkışını denetlemeyi de deneyebilirsiniz. Kilit İzleyicisi, ek kilit bilgileri içermesi dışında Standart Monitör ile aynıdır. Bu ek kilit ve kilitlenme bilgilerini görüntülemek için innodb status\G komutunu çalıştırın.

Sonraki adımlar

MySQL binlog çoğaltmaya genel bakış bölümünü gözden geçirin.