g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Mysql veritabanı kontrol noktası mekanizmasının ayrıntılı açıklaması, toplamaya değer

Genel Bakış

Mysql veritabanının kontrol noktası hala Oracle'a çok benziyor, hadi birlikte bir göz atalım ~

Giriş

Sahneler : Yineleme günlüğü süresiz olarak büyüyebiliyorsa ve arabellek havuzu yeterince büyükse, arabellek havuzundaki sayfaların yeni sürümünü diske geri göndermeye gerek yoktur. Çünkü bir kesinti meydana geldiğinde, tekrarlama günlüğü aracılığıyla tüm veritabanı sistemindeki verileri kesinti anına geri yüklemek tamamen mümkündür.

Ancak bu iki önkoşul gerektirir: 1. Arabellek havuzu, veritabanındaki tüm verileri önbelleğe alabilir; 2. Yineleme günlüğü süresiz olarak artabilir

Bu nedenle, Checkpoint teknolojisi aşağıdaki sorunları çözmek için doğmuştur: 1. Veritabanının kurtarma süresini kısaltın; 2. Arabellek havuzu yeterli olmadığında, kirli sayfaları diske boşaltın; 3. Yineleme günlüğü kullanılamadığında, yenileyin Kirli sayfalar.

Veritabanı çalışmadığında, veritabanının tüm günlükleri yeniden yapması gerekmez, çünkü Kontrol Noktasından önceki sayfalar diske geri aktarılmıştır. Veritabanının yalnızca Checkpoint'ten sonra yineleme günlüğünü kurtarması gerekir, bu da kurtarma süresini büyük ölçüde kısaltır.
Tampon havuzu yeterli olmadığında, en son kullanılan sayfa LRU algoritmasına göre taşacaktır.Sayfa kirli bir sayfaysa, sayfanın yeni sürümü olan kirli sayfayı diske geri döndürmek için kontrol noktasının zorlanması gerekir.
Yineleme günlüğü kullanılamaz hale geldiğinde, mevcut işlem veritabanı sistemi yineleme günlüğünü geri dönüştürmek için tasarlandığından, sonsuza kadar artmasına izin verilmez.Yineleme günlüğü yeniden kullanılabilir, bu yineleme günlüklerinin artık mevcut olmadığı anlamına gelir. Yine, veritabanı çalışmadığında, yineleme günlüğünün bu kısmı veritabanı kurtarma işlemleri için gerekli değildir, bu nedenle bu kısmın üzerine yazılabilir ve yeniden kullanılabilir. Yineleme günlüğünün hala kullanılması gerekiyorsa, denetim noktası arabellek havuzundaki sayfaları en azından geçerli yineleme günlüğü konumuna boşaltmaya zorlanmalıdır.

InnoDB depolama motoru için, sürüm LSN (Günlük Sıra Numarası) ile işaretlenmiştir.

LSN, 8 baytlık bir sayıdır, her sayfada LSN, yineleme günlüğünde ayrıca LSN bulunur, denetim noktasında ayrıca LSN bulunur. Şunları gözlemlemek için SHOW ENGINE INNODB STATUS komutunu kullanabilirsiniz:

mysql > motor innodb durumunu göster \ G

Checkpoint için zamanlama, koşullar ve kirli sayfaların seçimi çok karmaşıktır. Checkpoint'in yaptığı şey, arabellek havuzundaki kirli sayfaları diske geri göndermekten başka bir şey değildir. Aradaki fark, her seferinde diske kaç sayfanın boşaltıldığı, her defasında kirli sayfaların getirildiği ve Kontrol Noktası'nın ne zaman tetiklendiğidir.

İki, Kontrol noktası sınıflandırması

InnoDB depolama motorunda iki tür Kontrol Noktası vardır: Keskin Kontrol Noktası, Bulanık Kontrol Noktası

Sharp Kontrol Noktası, veritabanı kapatıldığında tüm kirli sayfaları diske geri çeker.Bu, varsayılan çalışma modudur, yani innodb_fast_shutdown = 1 parametresidir. Ancak veritabanı, çalışma zamanında Sharp Checkpoint'i de kullanıyorsa, veritabanının kullanılabilirliği büyük ölçüde etkilenecektir. Bu nedenle, InnoDB depolama motorunun içinde Fuzzy Checkpoint, sayfaları yenilemek için kullanılır, yani, tüm kirli sayfaları diske geri yüklemek yerine, kirli sayfaların yalnızca bir kısmı yenilenir.

Bulanık Kontrol Noktası : 1. Ana İş Parçacığı Kontrol Noktası; 2. FLUSH_LRU_LIST Denetim Noktası; 3. Eşzamansız / Eşitleme Yıkama Denetim Noktası; 4. Kirli Sayfa çok fazla Denetim Noktası

1. Ana Konu Kontrol Noktası

Arabellek havuzunun kirli sayfa listesindeki sayfaların belirli bir yüzdesini her saniyede veya on saniyede bir hızla diske geri yükleyin. Bu işlem eşzamansızdır. Şu anda InnoDB depolama motoru diğer işlemleri gerçekleştirebilir ve kullanıcı sorgu dizisi engellenmez.

2. FLUSH_LRU_LIST Kontrol Noktası

Çünkü InnoDB depolama motorunun, LRU listesinde kullanılmak üzere neredeyse 100 ücretsiz sayfanın mevcut olmasını sağlaması gerekir. InnoDB1.1.x'ten önce, LRU listesinde yeterli boş alan olup olmadığını kontrol etmeniz gerekir İşlem, kullanıcının sorgu işlemini açıkça engelleyen kullanıcı sorgu dizisinde gerçekleşir. Kullanılabilir 100 boş sayfa yoksa InnoDB depolama motoru, LRU listesinin sonundaki sayfaları kaldıracaktır. Bu sayfalarda kirli sayfalar varsa, o zaman kontrol noktası gereklidir ve bu sayfalar LRU listesindendir, bu nedenle bunlara FLUSH_LRU_LIST Kontrol Noktası denir.

MySQL sürüm 5.6'dan, yani InnoDB1.2.x'ten başlayarak, bu kontrol ayrı bir Sayfa Temizleyici iş parçacığında gerçekleştirilir ve kullanıcı, innodb_lru_scan_depth parametresi aracılığıyla LRU listesindeki kullanılabilir sayfaların sayısını kontrol edebilir. Varsayılan değer şu şekildedir: 1024, örneğin:

mysql > 'İnnodb_lru_scan_depth GİBİ KÜRESEL DEĞİŞKENLERİ GÖSTER ';

3. Async / Sync Flush Kontrol Noktası

Yineleme günlük dosyasının kullanılamadığı durumu ifade eder.Şu anda, bazı sayfaların diske geri yüklenmesini zorlamak gerekir ve kirli sayfalar kirli sayfa listesinden seçilir. Yineleme günlüğüne yazılan LSN redo_lsn olarak kaydedilirse ve diskin en son sayfasına geri gönderilen LSN checkpoint_lsn olarak kaydedilirse, şunları tanımlayabilirsiniz:

checkpoint_age = redo_lsn-checkpoint_lsn

Ardından aşağıdaki değişkenleri tanımlayın:

async_water_mark =% 75 * total_redo_log_file_size

sync_water_mark =% 90 * total_redo_log_file_size

Her bir yineleme günlük dosyasının boyutu 1 GB ise ve iki yineleme günlüğü dosyası tanımlanmışsa, yineleme günlük dosyasının toplam boyutu 2 GB'tır. Sonra async_water_mark = 1.5GB, sync_water_mark = 1.8GB. sonra:

Checkpoint_age ne zaman < Async_water_mark olduğunda, kirli sayfaları diske atmaya gerek yoktur;

Async_water_mark olduğunda < checkpoint_age < Eşzamansız Yıkama, sync_water_mark olduğunda tetiklenir ve yeterince kirli sayfa Yıkama listesinden diske geri akıtılır, böylece kontrol noktası_ajı temizlemeden sonra karşılanır < async_water_mark;

checkpoint_age > Bu sync_water_mark durumu, yineleme günlük dosyası kümesi çok küçük olmadığı ve LOAD DATA'ya benzer bir TOPLU EKLEME işlemi gerçekleştirilmediği sürece nadiren meydana gelir. Bu noktada, Senkronizasyon Yıkama işlemi, temizlemeden sonra checkpoint_age'in karşılanması için Yıkama listesinden yeterince kirli sayfayı diske boşaltmak için tetiklenir. < async_water_mark.

Async / Sync Flush Checkpoint'in günlük geri dönüşümü yinelemenin kullanılabilirliğini sağlamak için olduğu görülebilir. InnoDB 1.2.x'ten önce, Async Flush Checkpoint sorunu bulan kullanıcı sorgu iş parçacıklarını engellerken, Sync Flush Checkpoint tüm kullanıcı sorgu iş parçacıklarını engeller ve kirli sayfa yenilemesinin tamamlanmasını beklerdi. InnoDB 1.2.x sürümünden, yani MySQL 5.6 sürümünden başlayarak, yenileme işleminin bu bölümü de ayrı bir Sayfa Temizleyici İş Parçacığına yerleştirilir, böylece kullanıcı sorgu dizisi engellenmez.

MySQL'in resmi sürümü, yenileme sayfasının Flush listesinden mi yoksa LRU listesinden mi kontrol edildiğini kontrol edemez ve yineleme günlükleri nedeniyle oluşturulan Async / Sync Flush sayısını bilmez. Bununla birlikte, InnoSQL sürümü SHOW ENGINE INNODB STATUS komutu aracılığıyla gözlemlenebilen yöntemler sağlar, örneğin:

mysql > motor innodb durumunu göster \ G;

4. Kirli Sayfa çok fazla

Yani, kirli sayfaların sayısı çok fazla ve InnoDB depolama motorunun bir kontrol noktasını zorlamasına neden oluyor. Genel olarak amacı, ara bellek havuzunda yeterince boş sayfa olmasını sağlamaktır. İnnodb_max_dirty_pages_pct parametresi ile kontrol edilebilir:

mysql > GİBİ KÜRESEL DEĞİŞKENLERİ GÖSTERİNnodb_max_dirty_pages_pct ';

75'in innodb_max_dirty_pages_pct değeri, arabellek havuzundaki kirli sayfaların sayısı% 75'i kapladığında, denetim noktasının kirli sayfaların bir bölümünü diske yenilemeye zorlandığı anlamına gelir. InnoDB 1.0.x'ten önce, bu parametrenin varsayılan değeri 90'dı ve sonraki tüm sürümler için 75'ti.

Üç, Kontrol noktası mekanizması

Innodb işlem günlüğünde Fuzzy Checkpoint kullanılır. Innodb her seferinde en eski değiştirilen sayfaya (son kontrol noktası) karşılık gelen LSN'yi getirir ve ardından bu kirli sayfanın LSN'sini günlük dosyasına bir Kontrol noktası noktası olarak kaydeder, bu da "önceki LSN LSN'ye karşılık gelen günlük ve veriler, yineleme günlüğüne temizlendi

Mysql çöktüğünde Innodb, yineleme günlüğünü tarar ve son denetim noktasından son denetim noktasına karşılık gelen LSN, Log temizlenen günlüğüne karşılık gelen LSN'ye eşit olana kadar arabellek havuzuna yineleme günlüğünü uygular ve kurtarma işlemi tamamlanır.

Peki tam olarak nasıl iyileşti?

Yukarıdaki şekilde gösterildiği gibi, Innodb'un işlem günlüğü 4 aşamadan geçti:

Oluşturma aşaması: işlem bir günlük oluşturur;
Günlük temizleme: Günlük, diskteki günlük dosyasına yazılır;
Veri temizleme: günlüğe karşılık gelen kirli sayfa verileri diskteki veri dosyasına yazılır;
CKP Yaz: Günlük, günlük dosyasına bir Kontrol Noktası olarak yazılır;

Bu 4 aşamaya karşılık gelen sistem, çeşitli diğer işleme kullanımları için logla ilgili 4 bilgi kaydeder:

Günlük sıra numarası (LSN1): Mevcut sistem LSN'sinin maksimum değeri, yeni işlem günlüğü LSN bu temelde üretilecektir (LSN1 + yeni günlüğün boyutu);
Günlük (LSN2) 'ye kadar temizlendi: Şu anda günlük dosyasına yazılan LSN;
En eski değiştirilmiş veri günlüğü (LSN3): Mevcut en eski kirli sayfa verilerine karşılık gelen LSN Bu LSN, Kontrol Noktası yazılırken doğrudan günlük dosyasına yazılır;
Son kontrol noktası (LSN4): Şu anda Kontrol Noktasına yazılan LSN;

Sistem için yukarıdaki 4 LSN azalıyor, yani: LSN1 > = LSN2 > = LSN3 > = LSN4.

Dört, günlük koruma mekanizması

Bir mysql çökmesi meydana geldiğinde, Innodb, innodb_flush_log_at_trx_commit parametresi tarafından kontrol edilebilen bir günlük temizleme mekanizmasına sahiptir. Günlük kapsamının neden olduğu günlük kaybını nasıl önleyeceğiniz aşağıda açıklanmıştır.

Innodb'un kontrol noktası ile yeniden günlüğü arasındaki yakın ilişki nedir? Açıklanması gereken birkaç terim var:

Ckp yaşı (dinamik hareket): En eski kirli sayfa veri dosyasına boşaltılmadı, yani son kontrol noktası aralıkta değil
Buf yaş (dinamik hareket): Değiştirilen sayfa bilgileri günlüğe yazılmaz, ancak zaten günlük arabelleğinde bulunur
Buf async (sabit nokta): Günlük alanı boyutunun 7 / 8'i Buf yaşı Buf async noktasına hareket ettiğinde, günlüğe yazılmamış değiştirilmiş sayfa bilgileri, işlemi engellemeden günlüğe yazmaya başlamak zorunda kalır.
Buf senkronizasyonu (sabit nokta): Günlük alanı boyutunun 15 / 16'sı. Yazma büyük olduğunda, tampon yaşı çok hızlı hareket eder ve tampon senkronizasyon noktasına bir kerede ulaşılır, işlemi engeller ve değiştirilen sayfa bilgilerini günlüğe yazmaya başlaması için zorlar . İşlem engellenmemişse, son kontrol noktası olmadan tekrarlama günlüğünün üzerine yazma tehlikesi vardır
Ckp async (sabit nokta): Günlük alanı boyutunun 31/32'si, ckp yaşı ckp async'e ulaştığında, son kontrol noktası işlemi engellememeye zorlanır
Ckp senkronizasyonu (sabit nokta): günlük alanı boyutu, ckp yaşı ckp senkronizasyonuna ulaştığında, son kontrol noktası işlemi engellemeye zorlanır, günlüğü tekrarlama kapsamı tehlikesi vardır

Daha sonra daha fazla devop ve DBA içeriği paylaşacağım ve ilgilenen arkadaşlar buna dikkat edebilir ~