İnnodb_flush_log_at_trx_commit = 2 kullanmak güvenli midir?

Döndüm innodb_flush_log_at_trx_commit = 2ve çok hızlı bir yazma hızı elde ettim . Ancak üretim web sitesinde kullanılması güvenli midir?

Bir saniyenin işlem değerine kadar kaybedebilirsiniz. InnoDB ACID Uyumlu tutmaya yardımcı olan varsayılan değer 1'dir .

İnnSdb_flush_log_at_trx_commit adresindeki MySQL Dokümantasyonuna göre

İnnodb_flush_log_at_trx_commit'in değeri 0 ise, günlük arabelleği saniyede bir kez günlük dosyasına yazılır ve disk dosyasına temizleme işlemi günlük dosyasında gerçekleştirilir, ancak işlem gerçekleştirme işleminde hiçbir şey yapılmaz. Değer 1 (varsayılan) olduğunda, günlük arabelleği her işlem sırasında günlük dosyasına yazılır ve günlük dosyasında diske basma işlemi gerçekleştirilir. Değer 2 olduğunda, günlük arabelleği her işleme sırasında dosyaya yazılır, ancak diske basma işlemi üzerinde gerçekleştirilmez. Ancak, günlük dosyasındaki temizleme işlemi, değer 2 olduğunda da saniyede bir kez gerçekleşir. İşlem zamanlaması sorunları nedeniyle saniyede bir kez temizleme işleminin her saniye gerçekleşmesi% 100 garantili değildir.

Tam ACID uyumluluğu için 1 varsayılan değeri gereklidir. Değeri 1'den farklı olarak ayarlayarak daha iyi performans elde edebilirsiniz, ancak daha sonra bir çarpışmada bir saniyeye varan işlem kaybına uğrayabilirsiniz. 0 değeri ile herhangi bir mysqld işlem çökmesi işlemlerin son saniyesini silebilir. 2 değerinde, yalnızca bir işletim sistemi çökmesi veya elektrik kesintisi işlemlerin son saniyesini silebilir. InnoDB'nin kaza kurtarma değeri ne olursa olsun çalışır.

İşlemlerle InnoDB kullanan bir çoğaltma kurulumunda olası en yüksek dayanıklılık ve tutarlılık için ana sunucunuz my.cnf dosyanızdaki innodb_flush_log_at_trx_commit = 1 ve sync_binlog = 1 komutunu kullanın.

Uyarmak, ihtar etmek, dikkat çekmek

Birçok işletim sistemi ve bir miktar disk donanımı, diski temizleme işlemini kandırır. MySQL'e floşun gerçekleştiğini bile söylemiş olabilirler. O zaman işlemlerin dayanıklılığı ayar 1'de bile garanti edilmez ve en kötü durumda elektrik kesintisi InnoDB veritabanını bile bozabilir. Pil destekli bir disk önbelleğini SCSI disk denetleyicisinde veya diskin içinde kullanmak dosya temizlemelerini hızlandırır ve işlemi daha güvenli hale getirir. Ayrıca, disk önbelleklerinin donanım önbelleklerinde önbelleğe alınmasını devre dışı bırakmak için Unix komut hdparm'ı kullanmayı deneyebilir veya donanım satıcısına özgü başka bir komut kullanabilirsiniz.

Buna dayanarak, 1 dışındaki değerler InnoDB'yi 1 saniyelik işlemlerin veya bir işlem taahhüdünün veri değerlerini kaybetme riskine sokar.

Belgeler ayrıca kullanım diyor sync_binlog=1.

Sync_binlog'daki MySQL Belgesine göre

1 değeri en güvenli seçimdir, çünkü bir çökme durumunda en fazla bir deyimi veya ikili günlükten yapılan işlemi kaybedersiniz. Ancak, aynı zamanda en yavaş seçimdir (diskte batarya destekli önbellek bulunmadığı sürece senkronizasyonu çok hızlı yapar).

En güvenli seçiminiz

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Olası veri kaybına aldırış etmezseniz (1 saniyeye kadar), o zaman ödüller (daha hızlı yazma hızı) buna değiyorsa, 0 veya 2 riski kendi sorumluluğunuzdadır.

innodb_flush_log_at_trx_commitOlarak amacı ile kullanılır ..

Değeri innodb_flush_log_at_trx_commit 0 ise, günlük arabellek, günlük dosyasına saniyede bir kez yazılır ve günlük dosyasına disk işlenişi işlemi gerçekleştirilir, ancak bir işlem gerçekleştirme işleminde hiçbir şey yapılmaz.

Değer 1 (varsayılan) olduğunda, günlük arabelleği her işlem sırasında günlük dosyasına yazılır ve günlük dosyasında diske basma işlemi gerçekleştirilir.

Değer 2 olduğunda, günlük arabelleği her işleme sırasında dosyaya yazılır, ancak diske basma işlemi üzerinde gerçekleştirilmez. Ancak, günlük dosyasındaki temizleme işlemi, değer 2 olduğunda da saniyede bir kez gerçekleşir. İşlem zamanlaması sorunları nedeniyle saniyede bir kez temizleme işleminin her saniye gerçekleşmesi% 100 garantili değildir.

Tam ACID uyumluluğu için 1 varsayılan değeri gereklidir. Değeri 1'den farklı olarak ayarlayarak daha iyi performans elde edebilirsiniz, ancak daha sonra bir çarpışmada bir saniyeye varan işlem kaybına uğrayabilirsiniz. 0 değeri ile herhangi bir mysqld işlem çökmesi işlemlerin son saniyesini silebilir. 2 değerinde, yalnızca bir işletim sistemi çökmesi veya elektrik kesintisi işlemlerin son saniyesini silebilir. InnoDB'nin kaza kurtarma değeri ne olursa olsun çalışır.

Bence innodb_flush_log_at_trx_commit2'yi kullanmak bir sorun olmamalı. Fakat 1'i kullanmak en güvenli olanı.

Benim düşüncem diğerlerinden farklı. innodb_flush_log_at_trx_commit = 0 eğer: eğer benim geliştirme bilgisayarım ya da hassas mini veri olmayan ev mini veritabanım.

innodb_flush_log_at_trx_commit = 2 eğer: blog / istatistik / e-ticaret (günde ~ 100x mağazasıyla) vs.

innodb_flush_log_at_trx_commit = 1 eğer: eğer çok müşteriniz varsa veya banka gibi para ile çalışmanız gerekiyorsa. bu yüzden hız ve güvenliğe sahip olmak için veri akışınızı birkaç sunucu arasında paylaştırmalısınız.

Ben 2'yi tercih ediyorum, çünkü ~ 75x daha hızlı yazma hızına sahip ve SADECE donanım arızalandığında başarısız oluyor.

Her neyse, daha fazla yazma hızına veya 1 saniyeye kadar bilgiye ne ihtiyacınız olduğunu biliyor olmalısınız?

Cevap vermeye çalışıyorum, amacı nedir innodb_flush_log_at_trx_commit?

InnoDB işlemlerinin çoğunu bellekte gerçekleştirir ( InnoDB Buffer Pool). Ayrıca, değiştirilen veriler InnoDB transaction log filekalıcı depolamaya (sabit disk) yazılır ve sonra temizlenir.

Veri güvenliği ( Durability from ACID) için InnoDB, her bir işlemin değiştirilmiş verilerini kalıcı bir depoya kaydetmelidir. Aynı zamanda, her işlem için diske adamak pahalı bir işlemdir.

Disk G / Ç engelleme işlemidir ve çok yavaştır, yavaş bir disktir, ayrıca InnoDB transaction per seconds(Disk verimi) sayısını azaltacaktır .

InnoDB, innodb_flush_log_at_trx_commitbu yıkama işleminin frekansını kontrol etmek için değişken sağlar . Değere bağlı olarak, InnoDB yıkama işlemi farklı davranır.

(Daha önce diğer cevaplarda açıklanmıştır)

0 - Her gün saniyede bir günlük dosyasına dosya yazıp diske yazılır (veriler, günlük havuzuna yazılmamış arabellek havuzundadır - performans artışı için). 1 - Bir işlem tamamlandığında diske yıkayın - varsayılan (Veri güvenliği için - ACID uyumluluğu) 2 - her işlem için günlük dosyasına yazın ve her saniyede diske yıkayın. (Performans kazancı için)

Uygulama gereksinimine ( Performance Vs data safety) bağlı olarak, bu değişkeni ayarlayabilirsiniz. 0 ile 2 arasındaki fark - her ikisi de performansı artıracaktır, 2 değeri verileri işlem dosyasında saklar ve çökme veya arıza durumunda kurtarılabilir, ancak 0'da olamaz.

Çoğu durumda, diske basmak, veriler InnoDB buffer pool (memory) to Operating systems cacheaslında depolama diskine yazılmadan yazılır (kalıcı depolama). Başarısızlık durumunda, en kötü durumda, bir saniyeye kadar veri kaybedebilirsiniz)

Performans kazancı çevreye bağlıdır ve kıyaslama yapabilir ve tanımlayabilirsiniz. Bir çoğaltma ortamında, veri güvenliği ve tutarlılığı için ayarlayın innodb_flush_log_trx_commit = 1ve sync_binlog=1.

Performans, uygulamanın asıl amacı ise, InnoDB, günlük yıkama sıklığını kontrol etmek için bir değişken sunar - innodb_flush_log_at_timeout- günlük yıkama sıklığı aralığını 1 to 2700 secondsvarsayılan olarak 1 olarak ayarlamanızı sağlar.

Yıkama aralığını N saniyeye kadar artırırken, performans kazancının N saniyeye kadar veri güvenliğinde uzlaşmanın sağlandığını unutmayın. Örneğin - yıkama 5 saniyede bir gerçekleşirse - verim kazancı çok yüksektir, ancak elektrik kesintisi veya sistem çökmesi durumunda, 5 saniyelik veriyi kaybedersiniz.

Bu makalede InnoDB kızarma ve işlem taahhüt işlemleri hakkında tartışılmaktadır .

Aws rds üzerinde mod 2'yi yaptıktan sonra değiştirebilirsiniz:

Bazı durumlarda değiştirilemez gibi çoğaltmanız çok azsa:

Donanımınız arızalanırsa, tüm verilerinizi kaybedebilirsiniz, bu yüzden param = 2'yi endişe etmeden kullanırım. Yine de sizi hassas (sipariş, sanal para, ...) ve normal (istatistik, araba, ...) verileri 2 db sunucular arasında bölüp güvenli ve hızlı tutabilirsiniz. Veritabanları arasındaki işlemler için http://dev.mysql.com/doc/refman/5.7/en/xa.html adresini kullanabilirsiniz.