Bütçede aksamayan MySQL yedeklemeleri

Geçerli MySQL yedekleme senaryom, db ikinci bir sunucuya çoğaltmak ve tablo veya satır kilitleme herhangi bir kesinti kaldırmak için o sunucuda mysqldump çalıştırmaktır. Bu iyi çalışıyor ama ikinci sunucu için aylık 150 $ maliyeti (Avustralya barındırma ABD'den çok daha pahalı.)

Burada bununla ilgili birçok soru okudum, çoğu insan planlanan yedeklemelerle ilgili yardıma ihtiyaç duyuyor ve neye ihtiyacım yok. Kesinti olmadan mysqldump (tercihen her 4 saatte bir) gerekir. Db ~ 7GB sıkıştırılmamış olduğundan, mysqldump sunucuya bağlı olarak biraz zaman alabilir.

Aynı makineye kopyalamayı düşündüm, ama kölenin çok ihtiyaç duyulan belleğe yemesini istemedim. Bellek kullanımını db bazında kısıtlayabilirim emin değilim? Her iki durumda da, bu db boşaltma sırasında sunucuya yük koyacaktır.

Ben sadece bu http://www.zmanda.com/quick-mysql-backup.html okudum ve iyi görünüyor, yılda 300 $ tamam, bu beni çok kurtarır.

Ne yazık ki Amazon'un RDS'ye çoğaltılamıyorum ama bir mikro RC2 örneğine çoğaltılabilirim ama çoğaltma aşırı net gerçekleşecek ve ping ~ 220ms.

Burada birkaç insanın iyi bir seçenek olabilecek LVM anlık görüntüleri hakkında konuştuğunu gördüm. Bu seçenek hakkında pek bir şey bilmiyorum tho.

Görüşler çok takdir edilecektir.

Innodb tabloları kullanıyorsanız,

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Bu da kilitlemeden araçları tarafından içe aktarılabilecek veritabanınızın dökümünü alacaktır. Eğer myisam tabloları varsa o kilitler inanıyorum.

Innodb veya tamamen işlemsel başka bir arka uç kullanıyorsanız, kullanabilirsiniz mysqldump --single-transaction .... Bunu iyi sonuçlarla oldukça büyük (~ 100GB) veritabanlarında kullandım; veritabanı ağır yük altında ise saatler sürebilir, ancak tablolarınızı kilitlemeden çalışır. Çoğaltma genellikle daha iyidir, ancak bazen güzel bir sağlam döküm dosyası istersiniz. Bir mysql çoğaltma slaveini de atabileceğinizi unutmayın.

Mysqldump sayfasından (işleme sızacak işlemler hakkında dikkat edin):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

ABD'de ucuz bir VPS ile yüksek gecikme bağlantısı üzerinden çoğaltma konusunda bir sorun görmüyorum. Çoğaltma, bir köle saatlerce geride kalsa bile çabucak yetişebilecek şekilde tasarlanmıştır , yani eşzamansız olarak çalışabilir.

Sürece Avustralya hosting planında bu kadar giden bant genişliği dayanabilir.

Yüksek gecikmenin önemli olup olmayacağı konusunda çok daha ayrıntılı bir cevap

Gerçekçi olarak, veritabanını gerçekten dışa aktarmak için gereken süre kesinti olacaktır. Yeterince yavaş bir süre boyunca yapın ve herhangi bir sorun olmamalıdır. Bu bütçeyle ilgili bir BT departmanı gerçekten ne bekliyor?

7 GB'lık bir veritabanını 5-10 dakika MAX içinde mysqldump yapabilmeniz, okuma / yazma kilidini açabilmeniz ve kesinti süresinin sona ermesi gerekir. Daha sonra yeni sunucuya 7GB dosya için en bant genişliği etkili yolu bulabilirsiniz (okuma: YÜKSEK SIKIŞTIRMA). Dosyayı yeni sunucuda MySQL'e aktarıp almak için bolca zamanınız var. Ardından, masterlog bilgilerini girin ve çoğaltmayı başlatın. Çocuk oyuncağı olmalı!

MySQL belgeleri harika : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Bellek kullanımını db bazında kısıtlayabileceğimden emin değilim

Tabii ki yapabilirsiniz - sadece köleyi farklı bir /etc/my.cnf ile çalıştırmanız gerekiyor

Hatta nice / renice ve görev setini (bir Linux sunucusu olduğu varsayılarak) kullanarak master ve slave üzerindeki programlama önceliğini / CPU benzeşimini değiştirmek için bir şeyler yapabilirsiniz.

ancak çoğaltma aşırı net gerçekleşir ve ping ~ 220ms olur

Gecikme hemen hemen önemsizdir - önemli olan bant genişliğidir - ve veritabanı bant genişliği (oturum verilerini çoğaltmadığınız varsayılırsa) HTTP bant genişliğinden daha az büyüklükteki birkaç sıradır.

Hiçbir kesinti ile [veritabanının tutarlı bir yedek oluşturmak] (tercihen her 4 saat) gerekir

Ancak tartıştığınız stratejiler, o zamanki gibi bir şeyde iyileşmeye izin vermiyor.

En ucuz seçeneğin aynı makinede bir köle olacağını düşünüyorum - ve yeniden yapılandırabileceğinizin ötesinde performansı olumsuz etkiliyorsa, mevcut barındırma paketini yükseltin.

Geçerli sunucuda bağlantısı kesilmiş bir slave: enable bin günlüklerini çalıştırmayı da düşünebilirsiniz. Bir yedek alın, yedeklemeyi yerel bir makineye geri yükleyin, sonra çöp kutusu günlüklerini döndürülürken kopyalayın ve yerel DBMS'de ileri doğru yuvarlayın .

Benim önerim:

1 - ikinci hesabınızı / sunucunuzu saklayın ve orijinal hesabınızdaki / sunucunuzdaki bir veritabanına çoğaltma uygulayın.

2 - ikinci hesaba / sunucuya çoğaltmayı durdurun.

3 - birkaç gün boyunca performansı izleyin. En yoğun dönemlerinizi içerecek kadar uzun süre izlediğinizden emin olun.

4 - büyük bir performans sorunu varsa eski kurulumunuza geçmeye hazır olun. İkinci hesabı korumanızın nedeni budur.

5 - orijinal hesabınızda daha fazla kapasite / yükseltme sunucusu satın alın. Bu iki sunucu için ödeme daha ucuz olmalı.

6 - ikinci hesabı iptal edin.

İyi şanslar!