Yüksek trafikli bir veritabanı sunucusunda çok dolu bir sabit sürücüye sahip olmak kötü mü?

Yüksek trafik üretim veritabanı sunucusu için MySQL ile bir Ubuntu sunucusu çalıştırmak. Makinede MySQL örneği dışında başka bir şey çalışmıyor.

Günlük veritabanı yedeklerini DB sunucusunda saklıyoruz, herhangi bir performans artışı veya sabit diski nispeten boş tutmamızın bir nedeni var mı? Disk, veritabanı ve tüm yedeklemelerle% 86 + 'ya kadar doldurulursa, performansa hiç zarar verir mi?

Peki,% 86-90 + tam kapasite ile çalışan DB sunucusu, sadece% 10 tam disk ile çalışan sunucudan daha az iyi performans gösterir mi?

Sunucudaki toplam disk boyutu 1 TB'ın üzerindedir, bu nedenle diskin% 10'u bile temel O / S değişimi ve bunun için yeterli olmalıdır.

Her şeyden önce veritabanı yedeklerinizi, veritabanınızla aynı fiziksel sürücüde veya RAID grubunda tutmak istemezsiniz. Bunun nedeni bir disk arızası (herhangi bir RAID koruması olmadan çalışıyorsanız) veya yıkıcı bir RAID arızası (RAID-1 veya RAID-5 kullanıyorsanız) veritabanınızı ve veritabanı yedeklerinizi kaybetmenize neden olacaktır.

Disk performansı ile ilgili sorunuz, bir disk sürücüsünün ne kadar dolu olduğu ile ilgili olup, diskteki verilere nasıl erişildiğine bağlıdır. Dönen diskler için G / Ç performansını etkileyen iki fiziksel faktör vardır. Onlar:

• arama süresi - disk sürücüsünü geçerli parça konumundan istenen verileri içeren parçaya taşımak için gereken disk sürücüsüdür.

• dönme gecikmesi - bu, sürücü dönerken istenen verinin okuma kafasına ulaşması için geçen ortalama süredir - 15K RPM sürücü için bu 2 ms'dir (milisaniye)

Sürücünüzün ne kadar dolu olduğu, sunucunuzun G / Ç'lerinin karşılaştığı ortalama arama süresini etkileyebilir. Örneğin, sürücünüz doluysa ve fiziksel olarak disk plakalarının aşırı zıt uçlarında sürücüde bulunan veritabanı tablolarınız varsa, bu tabloların her birinden gelen G / Ç'lere erişerek G / Ç'lerin yaşayacağı bu G / Ç'ler sürücünün maksimum arama süresi.

Bununla birlikte, sürücünüz doluysa ve uygulamanız sürücüde depolanan verilerin sadece küçük bir kısmına erişiyorsa ve tüm bu veriler sürücüde bitişik olarak bulunuyorsa, bu G / Ç'ler arama süresinden minimum düzeyde etkilenecektir. .

Ne yazık ki, bu sorunun cevabı "kilometreniz değişecektir", yani uygulamanızın verilere nasıl eriştiği ve bu verilerin nerede bulunduğu G / Ç performansınızın ne olacağını belirleyecektir.

Ayrıca, @gravyface tarafından belirtildiği gibi, işletim sistemi depolama gereksinimlerinizi veritabanınızdan ayırmak "en iyi yöntem" olacaktır. Yine, aynı işletim sistemine ve sürücünün veritabanı alanları arasında hem işletim sistemi hem de veritabanı yazılımı G / Ç istekleri yaparken sürekli arama yapılmasına neden olabileceğinden, disk yüzeyindeki kafa hareketini en aza indirmeye yardımcı olacaktır.

Burada dikkate alınması gereken iki açı vardır: Performans ve Sağlamlık.

Performans açısından, genellikle aşağıdakiler için ayrı disk iğlerine (veya RAID gruplarına / sürücü setlerine) sahip olmanız önerilir:

1. İşletim sistemi öğeleri (ikili dosyalar, günlükler, ev dizinleri vb.)
2. Takas alanı (takas kullanmayı beklemiyorsanız (1) ile birleştirilebilir)
3. Üretim DB
4. Üretim DB'sinin işlem günlükleri (kullanılıyorsa)
5. Veritabanı Dökümleri / Yedekleri

Bunun arkasındaki sebep oldukça basittir: DB performansının diski talep eden "diğer şeylerden" etkilenmesini istemezsiniz (örneğin, makine yoğun bir şekilde değiştirmeye başlarsa ve takas bölümü, DB verilerinden diskin diğer tarafındaysa, uzun disk ile uğraşmak istiyor).

Sağlamlık açısından, aynı tür bir arıza istersiniz, ancak farklı bir nedenden dolayı: Diğerlerinin işaret ettiği gibi, başarısız bir diskin hem DB'nizi hem de yedeklerini çıkarmasını istemezsiniz (gerçekçi olarak yedekleri kopyalamanız gerekir) sunucunun felaket durumunda arıza olması).

Ayrıca /, her şeyi içeren monolitik bir bölümle herhangi bir yapılandırmadan kaçınmak istersiniz - bu, diğer Unix benzeri sistemler tarafından paylaşılmayan Linux dünyasında yapılan talihsiz, trajik ve endişe verici şekilde yaygın bir hatadır.
Gravyface'nin yorumunda belirtildiği gibi, bir şekilde doldurmayı başarırsanız /, sisteminiz kesinlikle kesinlikle çökecektir ve sistem /iyi yapılandırılmış bir bağlantı hiyerarşisi yerine tek bir bölüme sahipse temizleme / kurtarma zaman alıcı ve maliyetli olabilir .

Veritabanı ve geçici (aşağıya bakınız) yedekleri root (/) 'dan farklı bir bölüme taşımanızı tavsiye ederim.

Ayrıca, (varsayılan) sıkıştırılmış veritabanı dökümü yedekleriniz için mantıklı bir döndürme / tutma şeması oluşturun. Yerel diskteki yedeklemelerin çoğunun bu kopyalarını saklamak için (genellikle) bir neden yoktur. Olağanüstü durum kurtarma için hiçbir şey yapmaz ve site dışına taşındığında, diskten çıkarılmalıdır.

Bu hemen hemen standart çalışma prosedürüdür.

Bu bana NetApp'da, neredeyse dosya dosyalarının performansının önemli ölçüde düştüğü (yarı gibi) bir hatayı hatırlattı. (kuşkusuz bu birkaç yıl önceydi).

Herkesin söylediği cevap buna bağlıdır, ama düşünmeye değer.

Tam dosya sistemlerinin ana dezavantajı, serbest düğümlerin listesinin parçalanması muhtemeldir ve her yerde.

Bir veritabanı için sabit diskte bulunan üç tür veri vardır.

1. Gerçek veritabanı dosyanız. Bu, genellikle büyük parçalar halinde büyüyen (örneğin% 10) büyük, önceden yerleştirilmiş bir dosya olacaktır.
2. Günlükler, sürekli olarak yazılan, silinen, yazılan vb. İşlem günlüğünüz ...
3. Bellekte çalışamayan büyük sorgular için geçici dosyalar.

(1) yalnızca dosya kümeniz için daha fazla alan ayrılırken boş alana ihtiyaç duyar. Veritabanınız büyümiyorsa, düşük disk alanı dosya sisteminden etkilenmemelidir. Yine de ayırıyorsa, veritabanınızı hemen parçaladığınız ve belleğe hazır olması gerektiğinde aramaya neden olduğunuz herhangi bir ücretsiz listeye sığmayan çok büyük bir yığın isteyebilir.

(2) alan tahsisini yönetmek ve onu silmek için işletim sistemini kullandığı günlüklerin saf bir şekilde çürümesi zarar görecektir. Veritabanınızın salt okunur olmadığı varsayılarak, sabit bir günlük akışı olacağı varsayılırsa, bunlar genellikle düşük sabit disk alanında parçalanır. Sonuçta bu yazma performansınıza zarar verecektir.

(3) tempDB, DB kalitesiz yazılı sorgular veya yeterli RAM için gerekmiyorsa, düşük disk alanından daha büyük sorunlarınız var demektir, çünkü okuma performansınız bile diske bağlı olabilir. Ayrıca MySql'nin tempDB için disk alanı ayırması gerekiyorsa ve sabit disk tükenirse, kesinti riskiyle karşılaşırsınız.

Yedeklemeler hakkında ...

1. Çalıştığım her işletme yedekleri aynı makinede tutar. Bir geri yükleme söz konusu olduğunda (yedekleri önemseyen, sayılan geri yüklemelerdir). Hiçbir şey aynı diskte orada db dosyasına sahip olma hızını geçecek.
2. Umarım açık, yedeklerin sadece yerel olmadığından emin olun.

Kısacası DB'nizin ağır yazmaması koşuluyla hayatta kalacağınızı söyleyebilirim. Öyleyse, düşük disk alanı bir sorundur. Ama ben senin yerinde olsaydım, er ya da geç aşağıdakiler üzerinde çalışırdım.

1. Yeterli RAM miktarım olduğunu onaylama
2. Günlükleri ve tüm geçici verileri DB'nizden ayırma.
3. İşletim sisteminizi ayırarak MySql'niz geri kalandan yüklenir.

Mümkünse ayrı iğler ve kontrolörler kullanın 1.

Ardından ayrı iğler

Bunu fakir bir adamın ayrı bölümleri izler.

Çoğaltma sunucularımdan birinde tüm disk alanını kullandığımda son zamanlarda benzer bir sorun yaşadım. Hemen etkisi çoğaltma çökmesine oldu ve sonra mysqld.sock dosyası açılamadı çünkü MySQL oturum olamazdı.