Bant genişliği endişelerini gidermek için MySQL 5.0 Replication'da ne yapabiliriz?

Uzak ana bilgisayara salt okunur köle olarak işlev görecek bir MySQL sunucusu 5.1 örneği ile yapılandırılmış istemci PC'de (Win) çalışacak bir uygulama geliştiriyorum. Uzak ana şemaları düzinelerce vardır, ancak her istemci için yalnızca bir tane gerekir, bu yüzden sadece istemcinin ihtiyaç duyduğu şemayı çoğaltmak için my.ini çoğaltma-do-db ayarı sağlar. Çoğaltma çalışır, ancak müşterilerimiz, internet erişiminin yalnızca veri kullanımı ile şarj edilen 3G kablosuz üzerinden kullanılabildiği dünyanın bölgelerine girdiklerinde, veri planı sınırlarını hızla aşarlar ve pahalı problemlerle karşılaşırlar.

Anladığım kadarıyla, MySQL tüm şemaların tüm işlemlerini tek bir binlog dosyasına yazar, bu da her istemcinin anadaki her şemada gerçekleştirilen tüm işlemleri indirmesi ve ardından indirildikten sonra, çoğaltma başına veritabanı filtresini uygulaması gerektiği anlamına gelir. istemcinin my.ini dosyasındaki do-db ayarları.

Bu verimsizliği en aza indirmek için, iletilen verileri% 50 oranında azaltmış gibi görünen slave_compressed_protocol = 1 ayarını kullandım , ancak yine de müşterimizin 3G faturasının veri limitini hızla aşmasına neden oluyor.

Bunun karşı karşıya olduğum tek kişi olduğumu hayal edemiyorum, bu yüzden x = y ayarlayarak bunu başarmak için bir ton cevap alacağımdan eminim. Bununla birlikte, böyle bir ayarın herhangi bir dokümanı veya önerilen bir yaklaşım bulamıyorum.

Şimdiye kadar, olası bir çözüm hakkındaki düşüncem, lütfen geri bildirim veya alternatif rotalar sağlayın:

1. Her şema için bir "proxy" bağımlı oluşturun (farklı bir kutuda veya farklı bir MySQL örneği / bağlantı noktasına sahip aynı kutuda)
2. Proxy slave'i, istemcilerin çoğaltmak istediği tek veritabanını çoğalt-do-db olarak yapılandırın.
3. İstemcinin MySQL örneğini uygun proxy slave'in slave'leri olarak yapılandırın.

Bu etmelidir istemci yalnızca kendi şeması için binlog verileri çekerek sonuçlanabilir. Olumsuz (söyleyebildiğim kadarıyla), kurulumumuzun karmaşıklığını önemli ölçüde artırması ve muhtemelen daha kırılgan hale getirmesidir.

Düşünceler? Bu yaklaşım işe yarayacak mı?

Not, RedHat üzerinde MySQL 5.0 sunucusunu çalıştırıyoruz, ancak bir çözüm üretiyorsa 5.5'e yükseltebiliriz.

ÖNERİ # 1: Dağıtım Ana Verilerini Kullanın

Dağıtım Yöneticisi, oturum açma kutusu etkin, oturum açma bağımlı güncelleştirmeleri etkinleştirilmiş bir mysql bağımlıdır ve yalnızca BLACKHOLE Storage Engine içeren tabloları içerir . Replicate-do-db komutunu Dağıtım Yöneticisi'ne uygulayabilir ve Dağıtım Yöneticisi'nde yalnızca ikili olarak yerleştirilmesini istediğiniz DB şemalarını içeren ikili günlükler oluşturabilirsiniz. Bu şekilde, Dağıtım Yöneticisi'nden giden binlog'ların boyutunu azaltırsınız.

Dağıtım Master'ı aşağıdaki gibi kurabilirsiniz:

1. mysqldump sadece şema dökümü oluşturmak için --no-data seçeneğini kullanarak veritabanı (ları).
2. Dağıtım Şemasına yalnızca şema dökümü yükleyin.
3. Dağıtım Yöneticisi'ndeki tüm tabloları BLACKHOLE depolama motoruna dönüştürün.
4. Gerçek veriler içeren bir ana bilgisayardan Dağıtım Yöneticisi'ne çoğaltma ayarlayın.
5. Dağıtım Yöneticisi'nin /etc/my.cnf dosyasına çoğaltma-do-db seçeneklerini ekleyin.

2. ve 3. adımlar için, yalnızca şema dökümünü düzenleyebilir ve ENGINE = MyISAM ve ENGINE = InnoDB yerine ENGINE = BLACKHOLE yazabilir ve sonra düzenlenmiş olan yalnızca şema dökümünü Dağıtım Yöneticisi'ne yükleyebilirsiniz.

Yalnızca 3. adımda, tüm MyISAM ve InnoDB tablolarının dağıtım ana dağıtımındaki BLACKHOLE'ye dönüştürülmesini kodlamak istiyorsanız, aşağıdaki sorguyu çalıştırın ve bir metin dosyasına gönderin:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Tablonun BLACKHOLE depolama motoruna dönüştürülmesine komut vermenin bir avantajı, MEMORY depolama motoru tablolarının da dönüştürülmesidir. MEMORY depolama motoru tablosu veri depolamak için disk alanı kaplamasa da bellek kaplar. MEMORY tablolarını BLACKHOLE'a dönüştürmek, dağıtım yöneticisinde belleği düzenli tutacaktır.

Dağıtım Yöneticisi'ne herhangi bir DDL göndermediğiniz sürece, istemcilerin yalnızca istedikleri DB bilgilerini çoğaltmasına izin vermeden önce istediğiniz herhangi bir DML'yi (INSERT, UPDATE, DELETE) iletebilirsiniz.

Zaten bir dağıtım yöneticisi kullanarak tartışan başka bir StackExchange sitesinde bir yazı yazdım .

ÖNERİ # 2: Daha Küçük İkili Günlükleri ve Röle Günlüklerini Kullanın

Max_binlog_size değerini gülünç derecede küçük bir şeye ayarlarsanız, binlog'lar daha küçük parçalar halinde toplanabilir ve gönderilebilir. Ayrıca, röle günlüklerinin boyutunu ayarlamak için ayrı bir seçenek vardır, max_relay_log_size . Max_relay_log_size = 0 ise, varsayılan olarak max_binlog_size olarak ayarlanan değere ayarlanır.

ÖNERİ # 3: Yarı Senkronize Çoğaltma Kullan (yalnızca MySQL 5.5)

Ana veritabanınızı ve çoklu Dağıtım Yöneticilerini MySQL 5.5 olarak kurun. Ana veritabanının Binlog'ları Dağıtım Ana Verisine hızlı bir şekilde gönderebilmesi için Yarı Senkronize Çoğaltmayı etkinleştirin. TÜM köleleriniz Dağıtım Uzmanlarıysa, Yarı Senkronize Çoğaltma veya MySQL 5.5'e ihtiyacınız olmayabilir. Dağıtım Yöneticileri dışındaki herhangi bir köle, raporlama, yüksek kullanılabilirlik, pasif bekleme veya yedekleme amaçları için gerçek verilere sahipse, MySQL 5.5 ile Yarı Senkronize Çoğaltma ile birlikte gidin.

ÖNERİ # 4: Sıra Tabanlı DEĞİL İfade Tabanlı İkili Günlük Kaydı Kullan

SQL deyimi bir tabloda birden çok satırı güncelleştirirse, Deyime Dayalı İkili Günlük Kaydı (SBBL) yalnızca SQL deyimini depolar. Satır Tabanlı İkili Günlük Kaydı (RBBL) kullanan aynı SQL deyimi, her satır için satır değişikliğini gerçekte kaydeder. Bu, SQL deyimlerinin iletilmesinin RBBL üzerinden SBBL yapan ikili günlüklerde yer tasarrufu sağlayacağını açıkça ortaya koymaktadır.

Başka bir sorun, RBBL'yi tablo adının başında veritabanı bulunduğu replicate-do-db ile birlikte kullanmaktır . Bu bir köle için, özellikle bir dağıtım ustası için iyi olamaz. Bu nedenle, tüm DML'nin bir veritabanı ve tablo adlarının önünde bir nokta olmadığından emin olun.

Max_binlog_size önemsiz olmalıdır - binlog verileri sürekli olarak yayınlanır.

"Dağıtım Yöneticisi" ile ilgili uyarı - bu "tek hata noktası" dır. Yani, eğer ölürse, arkasındaki tüm slave (ler) veri almayacak ve rölenin yeniden inşası işe yarayacaktır.

SBR vs RBR - sorguya bağlıdır. Her ikisi de diğerinden daha iyi veya daha kötü olabilir.

Dağıtım Master'larını gerçek Master ile aynı makineye veya Master'a "yakın" bir makineye koyun. Örnekleri ayrı tutmak için ayrı bağlantı noktaları kullanın.