Apa yang bisa kita lakukan dalam Replikasi MySQL 5.0 untuk mengatasi masalah bandwidth?

Saya sedang mengembangkan aplikasi untuk dijalankan pada PC klien (Win) yang dikonfigurasi dengan server MySQL 5.1 contoh yang akan bertindak sebagai budak read-only ke master jarak jauh. Master jarak jauh memiliki puluhan skema, tetapi saya hanya perlu satu per klien sehingga saya menyediakan pengaturan replikasi-do-db di my.ini untuk hanya mereplikasi skema yang dibutuhkan klien. Replikasi bekerja, tetapi ketika klien kami masuk ke wilayah dunia di mana akses internet hanya tersedia melalui nirkabel 3G, yang membebani dengan penggunaan data, mereka dengan cepat melampaui batas paket data mereka dan mengalami masalah yang mahal.

Seperti yang saya pahami, MySQL menulis semua transaksi untuk semua skema ke dalam file binlog tunggal yang berarti bahwa setiap klien harus mengunduh semua transaksi yang dilakukan pada setiap skema pada master, kemudian setelah diunduh, terapkan filter database per replikasi- pengaturan do-db di file my.ini klien.

Untuk meminimalkan inefisiensi ini, saya telah menggunakan pengaturan slave_compressed_protocol = 1 , yang tampaknya mengurangi data yang ditransmisikan sebesar 50%, tetapi masih menyebabkan klien kami dengan cepat melebihi batas data mereka hingga tagihan 3G.

Saya tidak bisa membayangkan saya satu-satunya yang menghadapi ini, jadi saya yakin saya akan mendapatkan banyak jawaban tentang cara mencapai ini dengan menetapkan x = y. Namun, saya tidak dapat menemukan dokumentasi pengaturan semacam itu, atau pendekatan yang disarankan untuk diambil.

Sejauh ini, inilah pemikiran saya untuk solusi yang mungkin, berikan umpan balik atau rute alternatif:

Menyiapkan slave "proxy" untuk setiap skema (pada kotak yang berbeda, atau kotak yang sama dengan instance / port MySQL yang berbeda)
Konfigurasikan budak proksi untuk mereplikasi-do-db hanya satu basis data yang ingin ditiru klien.
Konfigurasikan instance MySQL klien sebagai budak ke budak proxy yang sesuai.

Ini akan mengakibatkan klien hanya menarik data binlog untuk skema mereka. Kelemahannya (sejauh yang saya tahu) adalah bahwa itu secara dramatis meningkatkan kompleksitas pengaturan kami, kemungkinan membuatnya lebih rapuh.

Pikiran? Apakah pendekatan ini akan berhasil?

Catatan, kami menjalankan server MySQL 5.0 di RedHat, tetapi kami dapat memutakhirkan ke 5,5 jika menghasilkan solusi.

— Abram
sumber

Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .

— Paul White mengatakan GoFundMonica

SARAN # 1: Gunakan Master Distribusi

Master Distribusi adalah budak mysql dengan log-bin diaktifkan, pembaruan log-slave diaktifkan dan hanya berisi tabel dengan Mesin Penyimpanan BLACKHOLE . Anda bisa menerapkan replicate-do-db ke Master Distribusi dan membuat log biner di Master Distribusi yang hanya berisi skema DB yang ingin Anda binlog. Dengan cara ini Anda mengurangi ukuran binlog keluar dari Master Distribusi.

Anda dapat menyiapkan Master Distribusi sebagai berikut:

mysqldump database Anda menggunakan opsi --no-data untuk menghasilkan dump skema saja.
Muat dump skema-saja ke Master Distribusi.
Konversikan setiap tabel dalam Master Distribusi ke mesin penyimpanan BLACKHOLE.
Setup replikasi ke Master Distribusi dari master dengan data nyata.
Tambahkan opsi replicate-do-db ke /etc/my.cnf dari Master Distribusi.

Untuk langkah 2 dan 3 Anda juga bisa mengedit dump skema saja dan ganti ENGINE = MyISAM dan ENGINE = InnoDB dengan ENGINE = BLACKHOLE dan kemudian memuat dump skema-diedit yang diedit ke Master Distribusi.

Pada langkah 3 saja, jika Anda ingin skrip konversi semua tabel MyISAM dan InnoDB ke BLACKHOLE di Master Distribusi, jalankan kueri berikut dan hasilkan ke file teks:

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

Bonus tambahan untuk penulisan tabel konversi ke mesin penyimpanan BLACKHOLE adalah mesin penyimpanan MEMORY tabel juga dikonversi. Sementara tabel mesin penyimpanan MEMORY tidak mengambil ruang disk untuk penyimpanan data, itu akan memakan memori. Mengubah tabel MEMORY ke BLACKHOLE akan membuat memori di Master Distribusi tidak berantakan.

Selama Anda tidak mengirim DDL ke Master Distribusi, Anda dapat mengirimkan DML (INSERT, UPDATE, DELETE) yang Anda inginkan sebelum membiarkan klien mereplikasi hanya informasi DB yang mereka inginkan.

Saya sudah menulis posting di situs StackExchange lain yang membahas menggunakan Master Distribusi .

SARAN # 2: Gunakan Log Biner Lebih Kecil dan Log Relay

Jika Anda mengatur max_binlog_size menjadi sesuatu yang sangat kecil, maka binlog dapat dikumpulkan dan dikirim dalam potongan yang lebih kecil. Ada juga opsi terpisah untuk mengatur ukuran log relai, max_relay_log_size . Jika max_relay_log_size = 0, itu akan default ke apa pun max_binlog_size diatur ke.

SARAN # 3: Gunakan Replikasi Semisinkron (khusus MySQL 5.5)

Setup database utama Anda dan beberapa Master Distribusi sebagai MySQL 5.5. Aktifkan Replikasi Semisinkron sehingga database utama dapat dengan cepat mengirimkan binlog ke Master Distribusi. Jika SEMUA budak Anda adalah Master Distribusi, Anda mungkin tidak perlu Replikasi Semisinkron atau MySQL 5.5. Jika ada budak, selain Distribution Master, memiliki data nyata untuk pelaporan, ketersediaan tinggi, siaga pasif atau cadangan, maka gunakan MySQL 5.5 bersama dengan Replikasi Semisynchronous.

SARAN # 4: Gunakan Binary Logging Berbasis Pernyataan BUKAN Berbasis Baris

Jika pernyataan SQL memperbarui beberapa baris dalam sebuah tabel, Penebangan Biner Berbasis Pernyataan (SBBL) hanya menyimpan pernyataan SQL. Pernyataan SQL yang sama menggunakan Binary Logging Berbasis Baris (RBBL) akan merekam perubahan baris aktual untuk setiap baris. Ini membuatnya jelas bahwa mengirimkan pernyataan SQL akan menghemat ruang pada log biner yang melakukan SBBL melalui RBBL.

Masalah lain adalah menggunakan RBBL dalam hubungannya dengan replicate-do-db di mana nama tabel memiliki basis data . Ini tidak baik untuk seorang budak, terutama untuk Master Distribusi. Oleh karena itu, pastikan semua DML tidak memiliki basis data dan periode di depan nama tabel apa pun.

— RolandoMySQLDBA
sumber

Gagasan menarik @Rando_MySQLDBA, Saran 1 terdengar seperti apa yang saya coba jelaskan dengan pengaturan budak "proxy" saya. Namun, DDL adalah sesuatu yang harus saya hubungkan dengan para budak. Saya kira saya bisa menangani ini di lapisan aplikasi, tetapi lebih suka tidak jika itu bisa dihindari. Saya bisa melihat bagaimana saran 2 akan membantu jika lalu lintas / kecepatan adalah masalah, tetapi tidak yakin bagaimana itu akan membantu penggunaan bandwidth bersih. Untuk saran 3, dapatkah Anda menjelaskan sedikit untuk saya? Saya pikir semisinkron akan lebih untuk replikasi "aman" ketika Anda perlu tahu setidaknya 1 budak mendapat pembaruan. Saran bagus BTW!

— Abram

@Abram Pastikan bahwa master distribusi tidak pernah menerima tabel InnoDB atau MyISAM untuk membatasi disk I / O ke manajemen binlog !!!

— RolandoMySQLDBA

Saat ini saya sedang menyiapkan lingkungan pengujian di mana saya akan memiliki beberapa instance MySQL 5.5 berjalan pada kotak yang sama (port diff) sebagai master distribusi. Setiap DM akan memiliki versi lubang hitam dari masing-masing DB dari master. Kemudian saya akan mengatur beberapa budak jarak jauh yang akan saya gantung di DM. Saya akan kembali dengan hasil saya. Kedengarannya seperti pilihan terbaik, meskipun untuk beberapa alasan saya khawatir menjalankan beberapa contoh MySQL. Mungkin pekerjaan untuk server cloud mikro dari amazon.

— Abram

@Abram, Anda harus menambahkan skip-innodb ke /etc/my.cnf. Anda tidak dapat menonaktifkan MyISAM karena merupakan mesin penyimpanan stok. Anda harus secara manual melakukan ALTER TABLE tblname ENGINE = BLACKHOLE jika tabel pada master distribusi akhirnya menjadi MyISAM. Mungkin membuat skrip dari kueri ini: SELECT CONCAT ('ALTER TABLE', table_schema, '.', Table_name, 'ENGINE = BLACKHOLE;') AlterCommand DARI information_schema.tables WHERE engine = 'MyISAM' dan table_schema NOT IN ('information_schema' , 'mysql'); Jika Anda menemukannya, cukup konversikan dari hasil kueri ini.

— RolandoMySQLDBA

Adapun saran # 3, replikasi semi-sinkron membuat master menerima pengakuan dari slave bahwa entri log membuatnya ke slave. Di bawah mysql 5.0, master menunggu sampai slave selesai memproses SQL sebelum mengirim pernyataan yang sama ke slave berikutnya. Dengan demikian, semi synch lebih cepat.

— RolandoMySQLDBA

Max_binlog_size seharusnya tidak relevan - data binlog dialirkan terus menerus.

Perhatian tentang "Master Distribusi" - ini adalah "satu titik kegagalan". Artinya, jika mati, semua budak di luarnya tidak akan menerima data, dan membangun kembali relai akan bekerja.

SBR vs RBR - itu tergantung pada permintaan. Entah bisa lebih baik atau lebih buruk dari yang lain.

Letakkan Master Distribusi pada mesin yang sama dengan Master asli, atau pada mesin "dekat" Master. Gunakan porta terpisah untuk memisahkan instans.

— Rick James
sumber