InnoDB işlem prensibi açıklandı
Bu makale, MySQL'in InnoDB depolama motoru işleminin gerçekleşme ilkesini popüler bir şekilde açıklayacak.
Her şeyden önce, işlemlerin ACID'nin dört özelliğine sahip olduğunu biliyoruz. Yani atomiklik, tutarlılık, izolasyon ve dayanıklılık.
Bu dört özelliği detaylandırmamıza gerek yok. Sadece işlemin bir dizi işlemin yürütüldüğünü veya yapılmadığını garanti ettiğini bilmemiz gerekiyor. Aynı zamanda, işlem tamamlandıktan sonra, yapılan değişiklikler veritabanına kalıcı olarak kaydedilecektir. Yapabilmek.
Şimdi InnoDB'nin işlemleri nasıl gerçekleştirdiğine bir göz atalım.
ACD'nin üç özelliği Günlüğü Yinele ve Geri Al günlüğü aracılığıyla gerçekleştirilir. İzolasyon kilitler ile sağlanır. Tecrit ve kilitlenme nedeniyle bir önceki yazıda bundan bahsetmiştim. Bu nedenle, bu makale Günlüğü Yinele ve Geri alma günlüğüne odaklanmaktadır.
Bir, Günlüğü yinele
Yineleme günlükleri, D özelliği olan işlem dayanıklılığını sağlamak için kullanılır. İki bölümden oluşur:
Bellekte yeniden günlük tamponu
Redo günlük dosyası
Bellek ve diskteki karşılık gelen iki varlığa baktığımızda, bunun verimlilik nedenleriyle yapılması gerektiğini biliyoruz, çünkü belleğin okuma ve yazma verimliliği disk okuma ve yazma verimliliğinden çok daha yüksektir.
Innodb, işlemleri destekleyen bir depolama motorudur.Bir işlem gerçekleştirildiğinde, işlemin tüm günlükleri yineleme günlük dosyasına yazılmalıdır ve işlemin tamamlanma işlemi tamamlandıktan sonra işlemin tamamı tamamlanır. Her yineleme günlük arabelleği yineleme günlük dosyasına yazıldıktan sonra, bir fsync işleminin çağrılması gerekir, çünkü günlük yineleme arabelleği yalnızca içeriği önce işletim sisteminin arabellek sistemine yazar ve doğrudan diske yazılmasını sağlamaz Bir fsync işlemi gerçekleştirilmelidir. Bu nedenle, diskin performansı da bir dereceye kadar işlem gönderme performansını belirler.
Fsync işlemiyle ilgili olarak, kullanıcılar müdahale edebilir, çünkü her işlem gönderildiğinde fsync yürütülür, bu da veritabanı performansını etkiler. Diskte günlük temizleme yineleme stratejisini kontrol etmek için innodb_flush_log_at_trx_commit aracılığıyla. Bu parametrenin varsayılan değeri 1'dir, yani her işlem gerçekleştirildiğinde bir fsync işlemi gerçekleştirilir. 0, işlem tamamlandığında yineleme günlük dosyasının yazılmayacağı anlamına gelir.Bu yazma işlemi ana iş parçacığı işlemi tarafından tamamlanır ve ana iş parçacığı her saniye yineleme günlük dosyasının fsync işlemini gerçekleştirir. 2, işlem tamamlandığında yineleme günlüğünün yineleme günlük dosyasına yazıldığı, ancak yalnızca dosya sisteminin önbelleğine yazıldığı ve hiçbir fsync işlemi yapılmadığı anlamına gelir. Kullanıcılar, tekrarlama günlüğünün dosyaya yazılmasını sağlamak için 0 veya 2 ayarlayarak veya 1 ayarlayarak işlem gerçekleştirme performansını artırabilir Kısacası, üç yöntemin kendi avantajları ve dezavantajları vardır.
Ayrıca bilmeniz gerekenler:
Yineleme günlük arabelleği, bellekteki günlük bloğunu diske atar: işlem gerçekleştirildiğinde (daha önce bahsedilmiştir), günlük arabelleğindeki bellek alanının yarısı kullanıldığında ve günlük kontrol noktası olduğunda.
Ardından, yineleme günlük dosyasında neyin depolandığını görmemiz gerekir.
Herkesin kafasının karışmasını önlemek için, depolama formatını tek tek detaylandırmayı planlamıyorum (gücüm yok, haha). Kabaca nasıl tasarladığını bilmemiz gerekiyor. Böylelikle ileride benzer bir sahneye sahip bir ürün tasarlarsak, tasarım fikirlerinden tam anlamıyla öğrenebiliriz.
Tamam, başlayalım:
InnoDB depolama motorunda, yineleme günlükleri 512 baytlık birimler halinde depolanır; bu, günlük önbelleğini yineleme ve yineleme günlük dosyası bloklarının, yineleme adı verilen bloklar halinde saklandığı anlamına gelir. Günlük bloğunu yeniden yap. Her bloğun boyutu 512 bayttır. Yineleme günlük bloğunun boyutu disk kesim boyutu ile aynı olduğundan, her ikisi de 512 bayttır, yineleme günlüğü yazma atomikliği garanti edebilir ve çift yazma teknolojisi gerektirmez.
Günlük kaydının kendisine ek olarak, her bir yineleme günlük bloğunun içeriği ayrıca iki bölümden oluşur: günlük bloğu başlığı ve günlük blok listesi. Yineleme günlüğü başlığı toplam 12 bayt, yineleme günlüğü kuyruğu ise 8 bayt kaplar. Bu iki parça sabittir. Bu nedenle, her bir yineleme günlüğü bloğunun gerçek depolama boyutu 492 bayttır (512-12-8) Aşağıdaki şekil, yineleme günlüğü bloğu önbelleğinin yapısını gösterir:
Şekilde bu alanların anlamlarına çok fazla dikkat etmenize gerek yok çünkü bunlar işlemleri gerçekleştirmek için Yinele günlüğü mekanizmasının anlaşılmasında pek bir etkiye sahip değiller, aksine bunlara dikkat ederseniz insanların bu büyük harf değişkenlerini görmesi ve baş dönmesi çok kolay.
ps: Bu değişkenler, günlük bloğunun durumunu koruyan bazı değişkenlerdir. Örneğin, günlük bloğunun mevcut kullanımını, geçerli yineleme bloğunun ilk yineleme günlüğünün başlangıç konumunu, vb. Gösterir. Örneğin:
T1 işleminin yineleme günlüğü 1762 bayt, T2 işleminin yineleme günlüğü ise 100 baytı kaplar. Her günlük bloğu aslında yalnızca 492 baytı depolayabildiğinden, günlük arabelleğindeki durumu aşağıdaki şekilde gösterildiği gibi olmalıdır:
Bu işlev, günlük bloğunun başlığındaki alanlar tarafından gerçekleştirilir. Pekala, bu bizim endişemiz değil, bundan sadece herkesin merakını gidermek ve bu değişkenler hakkındaki ilk anlayışı tatmin etmek için konuşuyorum.
Yineleme günlüğü bloğundaki üstbilgi ve tailer içeriği, belirli yineleme günlüğüdür. Farklı veritabanı işlemlerinin karşılık gelen yineleme günlük biçimleri olacaktır. Ek olarak, InnoDB depolama motorunun depolama yönetimi sayfa tabanlı olduğundan, yineleme günlük formatı da sayfa tabanlıdır. Farklı yineleme günlüğü biçimleri olsa da, şekilde gösterildiği gibi ortak bir başlık biçimine sahiptirler:
Genel başlık biçimi aşağıdaki 3 bölümden oluşur
redo_log_type: Günlük türünü yeniden yap
Uzay: Tablo alanı kimliği
sayfa numarası Sayfanın ofseti, sayfanın konumudur
Ondan sonra, yineleme günlüğü gövdesi gelir.Yineleme günlüğünün türüne bağlı olarak, farklı depolama içerikleri olacaktır.Örneğin, sayfada kayıtların eklenmesi ve silinmesi için, şekilde gösterilen biçime karşılık gelirler (yine, her alanın ayrıntılarını düşmeyin Anlamı, bu bizim dikkatimizin odak noktası değil):
Genel yineleme günlüğü yapısı tanıtıldı. Yineleme günlük dosyasından kurtarmadan bahsetmeden önce, LSN kavramından da bahsetmemiz gerekir.LSN, günlük sıra numarasını temsil eden Günlük Sıra Numarasının kısaltmasıdır. InnoDB depolama motorunda LSN 8 bayt kaplar ve monoton olarak artar.
LSN, işlem tarafından yineleme günlüğüne yazılan toplam bayt miktarını temsil eder. Örneğin, geçerli yineleme günlüğünün LSN'si 1000'dir. Bir T1 işlemi 100 baytlık bir yineleme günlüğü yazarsa, LSN 1100 olur. Başka bir T2 işlemi 200 baytlık bir yineleme günlüğü yazarsa, LSN 1300 oluyor.
LSN yalnızca yineleme günlüğünde kaydedilmez, aynı zamanda her sayfada da bulunur.Her sayfanın başında, sayfanın LSN'sini kaydeden bir FIL_PAGE_LSN değeri vardır. Sayfada LSN, sayfanın en son yenilendiği zamanki LSN'nin boyutunu temsil eder. . Yineleme günlüğü her sayfanın günlüğünü kaydettiğinden, sayfadaki LSN sayfanın geri yüklenmesinin gerekip gerekmediğini belirleyebilir. Örneğin, P1 sayfasının LSN'si 10000'dir ve veritabanı başlatıldığında, InnoDB yineleme günlüğüne yazılan LSN'nin 13000 olduğunu ve işlemin gerçekleştirildiğini, ardından veritabanının geri yüklenmesi gerektiğini algılar. Yineleme günlüğünü P1 sayfasına uygulayın. Benzer şekilde, LSN'si P1 sayfasından daha küçük olan yineleme günlüğündeki LSN için yeniden yapmaya gerek yoktur, çünkü P1 sayfasındaki LSN bu konuma ve bu konumdan önceki LSN İçerik başarıyla işlendi.
Bir sonraki adım, işlemi geri yüklemektir:
InnoDB depolama motoru başlatıldığında, çalıştırılan son verinin normalde kapatılmış olup olmadığına bakılmaksızın, tekrarlama günlüğü fiziksel günlüğü kaydettiği için (bunu karıştırmayın) kurtarmaya çalışacaktır, bu nedenle kurtarma hızı ikili günlük gibi mantıksal günlükten daha hızlıdır. Aynı zamanda, InnoDB depolama motorunun kendisi de kurtarma işlemini belirli bir dereceye kadar optimize etmiştir; örneğin, veritabanı kurtarma hızını daha da artırabilecek sıralı okuma ve yineleme günlüklerinin paralel uygulaması gibi.
Denetim noktası, disk sayfasına aktarılan LSN'yi temsil ettiğinden, kurtarma işlemi sırasında günlüğün yalnızca denetim noktasının başındaki kısmının geri yüklenmesi gerekir. Şekildeki örnek için, kontrol noktasının LSN'si 10000 olduğunda veritabanı çalışmadığında, kurtarma işlemi yalnızca LSN 10000 ila 13000 aralığındaki günlükleri geri yükler.
Fiziksel günlük
Örneğin, Ekleme işlemi için fiziksel günlük, her sayfanın değişikliklerini kaydeder:
SQL ifadesi çalıştırılırsa:
INSERT INTO t SELECT 1,2;
Kaydedilen yineleme günlüğü kabaca şuna benzer:
sayfa (2,3), ofset 32, değer 1,2
İki, Geri alma günlüğü
İkinci bölüm, Geri alma günlüğüdür, aşağıdaki ikisini gerçekleştirebilir Özellikleri:
1. İşlem geri dönüşünü gerçekleştirin
2. MVCC'yi uygulayın
Geri alma günlüğü ve yineleme günlüğü kaydı fiziksel günlüğün aynı değildir, mantıksal bir günlüktür. Bir kayıt silindiğinde, geri alma günlüğüne karşılık gelen bir ekleme kaydının kaydedildiği ve bunun tersi, bir kayıt güncellendiğinde, karşılık gelen bir güncelleme kaydını kaydettiği düşünülebilir.
Geri alma işlemi gerçekleştirirken, geri alma günlüğündeki mantıksal kayıttan ilgili içeriği okuyabilir ve geri alabilirsiniz. Bazen satır sürüm kontrolüne uygulandığında, geri alma günlüğü yoluyla da elde edilir: bir satır okunması diğer işlemler tarafından kilitlendiğinde, geri alma günlüğünden satır kaydının önceki verilerini analiz edebilir, böylece Kullanıcıların tutarlı, kilitlenmeyen okumalar elde etmelerine yardımcı olmak için sürüm bilgilerini satıra alın. Somut bir örnek verelim. Örnek bu makaleden geliyor.
Bu örnek, esas olarak bir kayıt satırının bir işlemle güncelleme sürecini gösterir:
Sunumdan önce şunu ekleyin:
InnoDB, MVCC'yi uygulamak için her kayıt satırı için üç gizli alan uygular:
- 6 baytlık işlem kimliği (DB_TRX_ID, bir işlem her işlendiğinde, değeri otomatik olarak +1 olur.
- 7 baytlık geri alma işaretçisi (DB_ROLL_PTR), geri alma segmentine yazılan bir geri alma günlük kaydını işaret eder.
- Gizli kimlik
1. İlk veri hattı
F1 F6 belirli kademelerin adlarıdır ve 1 6 karşılık gelen verilerdir. Son üç gizli alan, sırasıyla satırın işlem numarasına ve geri dönüş göstericisine karşılık gelir Bu veri sadece INSERT ise, ID 1 olarak kabul edilebilir ve diğer iki alan boştur.
2. İşlem 1, satırdaki her alanın değerini değiştirir
İşlem 1 satırın değerini değiştirdiğinde, aşağıdaki işlemler gerçekleştirilir:
- Sırayı özel bir kilitle kilitleyin
- Yineleme günlüğünü kaydet
- Değişiklikten önce satırın değerini kopyalayın (Kopyala olarak anlaşılabilir, ters güncellemeyi karıştırmayın ve buraya kopyalayın, ilke aynıdır) yukarıdaki şeklin en alt satırı olan geri alma günlüğüne kopyalayın
- Geçerli satırın değerini değiştirin, işlem numarasını girin ve geri alma işaretçisinin geri alma günlüğündeki değişiklikten önceki satırı işaret etmesini sağlayın.
3. İşlem 2, satırın değerini değiştirir
İşlem 1 ile aynı, şu anda geri alma günlüğünde iki satır vardır ve bunlar geri alma işaretçisi ile birbirine bağlanır.
Geri alma işaretçisi ile bağlanan bu satırlar, verilerin birden çok anlık görüntüsüne eşdeğerdir, böylece MVCC tutarlı kilitlenmeyen okumalar elde edilir.
Özel kurallar aşağıdaki gibidir:
InnoDB'nin MVCC'si, yukarıda bahsettiğimiz her kayıt satırının arkasındaki gizli sütunlarla gerçekleştirilir. Satırın oluşturulma zamanını ve satırın sona erme zamanını (veya silme süresini) depolarlar.Elbette, sakladıkları şey gerçek zaman değeri değil, sistem sürüm numarasıdır. Her yeni işlem başlatıldığında, sistem sürüm numarası otomatik olarak artırılır. İşlemin başındaki sistem sürüm numarası, sorgunun her satırının sürüm numarası ile karşılaştırılacak işlemin sürüm numarası olarak kullanılacaktır. TEKRARLANABİLİR READ izolasyon seviyesi altında, MVCC'nin spesifik işlemleri aşağıdaki gibidir:
SEÇ
InnoDB, her kayıt satırını aşağıdaki iki koşula göre kontrol edecektir:
- InnoDB, yalnızca sürümü geçerli işlem sürümünden daha eski olan, yani satırın sistem sürüm numarası işlemin sistem sürüm numarasından küçük veya ona eşit olan veri satırlarını bulur. Bu, işlem tarafından okunan satırların işlem başlamadan önce var olmasını veya İşlemin kendisi eklendi veya değiştirildi.
- Satırın silinen sürümü ya tanımsız ya da geçerli işlem sürüm numarasından daha büyük. Bu, işlem tarafından okunan satırların işlem başlamadan önce silinmemesini sağlar.
- Yalnızca yukarıdaki iki koşulu karşılayan kayıtlar sorgu sonuçları olarak döndürülebilir.
INSERT
- InnoDB, eklenen her satır için geçerli sistem sürüm numarasını satır sürüm numarası olarak kaydeder.
SİL
- InnoDB, silinen her satır için geçerli sistem sürüm numarasını bir satır silme tanımlayıcısı olarak kaydeder.
GÜNCELLEME
- InnoDB yeni bir satır ekler, mevcut sistem versiyon numarasını satır versiyon numarası olarak kaydeder ve aynı zamanda mevcut sistem versiyon numarasını satır silme tanımlayıcısı olarak orijinal satıra kaydeder.
Bunu okuduktan sonra bir soru olabilir. Aşağıdaki yürütme sırasını düşünün:
011.png
Önceki Seçim kuralına göre, B oturumunun işlemi A oturumundan sonra açılır, ardından B'nin işlem sürüm numarası, A işleminin sürüm numarasından büyüktür. Bu şekilde, A'ya eklenen veriler gönderilmediğinde, B, A tarafından değiştirilen verileri okuyabilir. Bu çelişkili değil mi?
Aslında öyle değil. InnoDB, tutarlı okuma sırasında veritabanı anlık görüntüsünü belirlemek için okuma görünümünü kullanır. InnoDB'nin okuma görünümü, bir kaydın görülebilip görülemeyeceğini belirler. İki kural vardır:
1 Okuma görünümü oluşturulduktan sonra başlatılan işlemleri göremiyorum
2 Okuma görünümü oluşturulduğunda aktif olan işlemleri göremiyorum
Oturum A için, okuma görünümü işlem başlatılırken oluşturulmaz, ancak güncelleme bildiriminde oluşturulur. Dolayısıyla, Oturum A'nın okundu görünümü, Oturum B'den sonra oluşturuldu. Yani B, A'nın işlemini görmeyecek. Bu nedenle tekrarlanamayan okuma engellenir.
İki kuralın orijinal açıklaması aşağıdaki gibidir:
Kural 1: Okunan görünüm nesnesi oluşturulduğunda, henüz bir işlem tanımlayıcısı olarak kullanılmayan en küçük işlem tanımlayıcısını not eder (trx_sys_t :: max_trx_id) .Okuma görünümü buna düşük limit adını verir.Bu nedenle, okuma görünümünü kullanan işlem herhangi bir işlem görmemelidir. bu düşük limite eşit veya daha büyük tanımlayıcıya sahip işlem.
Kural 2: Okuma görünümünü kullanan işlem, okuma görünümü oluşturulduğunda aktif olan bir işlemi görmemelidir.
Ek: Geri alma günlüğü silinmemişse, satırın oluşturulduğu andaki ilk içeriğine geri dönmek için mevcut kaydın geri alma işaretçisini kullanır.Neyse ki, Innodb'de en eskiden daha fazla olan aktif işlemleri sorgulayan bir temizleme iş parçacığı vardır. Geri alma günlüğü dosyasının sonsuza kadar büyümemesini sağlamak için erken geri alma günlüğü ve silin.
Yazar: küçük kuzeyi ara
Bağlantı: https://www.jianshu.com/p/9b83ea78b380
