Що ми можемо зробити в реплікації MySQL 5.0, щоб вирішити проблеми з пропускною здатністю?

Я розробляю програму для запуску на клієнтському ПК (Win), налаштованому на сервер MySQL 5.1 екземпляра, який буде виконувати функції невідомого доступу для віддаленого майстра. У віддаленого майстра є десятки схем, але мені потрібна лише одна на клієнта, тому я надаю налаштування реплікації do-db в my.ini, щоб лише повторити схему, необхідну клієнту. Реплікація працює, але коли наші клієнти потрапляють у регіони світу, де доступ до Інтернету доступний лише через 3G бездротовий зв’язок, який заряджається за допомогою даних, вони швидко перевищують обмеження свого плану даних та стикаються з дорогими проблемами.

Як я це розумію, MySQL записує всі транзакції для всіх схем у єдиний файл binlog, а це означає, що кожен клієнт повинен завантажувати всі транзакції, які виконуються на кожній схемі на майстер, а потім після завантаження застосувати фільтр баз даних на кожну реплікацію- налаштування do-db у файлі my.ini клієнта.

Щоб мінімізувати цю неефективність, я застосував налаштування slave_compression_protocol = 1 , яке, здається, зменшує передані дані на 50%, але все ж змушує нашого клієнта швидко перевищувати ліміт даних, що збільшує рахунок 3G.

Я не можу уявити, що я єдиний, хто стикається з цим, тому я впевнений, що отримаю багато відповідей, як цього досягти, встановивши x = y. Однак я не можу знайти жодної документації такого налаштування, ні рекомендованого підходу.

Поки, ось моя думка про можливе рішення, будь ласка, надайте зворотній зв'язок або альтернативні маршрути:

1. Налаштуйте підлеглий "проксі" для кожної схеми (в іншому вікні або в тому ж полі з іншим екземпляром / портом MySQL)
2. Налаштуйте підлеглий проксі-сервер для реплікації do-db лише тієї бази даних, яку клієнти хочуть копіювати.
3. Налаштуйте екземпляр MySQL клієнта як веденого до відповідного підлеглого проксі.

Це повинно призвести до того, що клієнт лише витягує дані binlog для своєї схеми. Мінусом (наскільки я можу сказати) є те, що він різко збільшує складність нашого налаштування, ймовірно, робить його більш крихким.

Думки? Чи навіть такий підхід спрацює?

Зауважте, ми запускаємо сервер MySQL 5.0 на RedHat, але ми можемо оновити до 5.5, якщо він виробляє рішення.

ПРИКЛАД №1: Використовуйте майстри розподілу

Мастер розповсюдження - це mysql-підлеглий з увімкненим журнальним біном, увімкнено оновлення ведомого журналу і містить лише таблиці з механізмом зберігання даних BLACKHOLE . Ви можете застосувати репліку-do-db до Магістра розподілу та створити бінарні журнали у розпоряднику дистрибутива, що містять лише схеми (и) БД, які ви хочете бінінгувати. Таким чином ви зменшуєте розмір вихідних бінологів від Master Master.

Ви можете налаштувати розпорядниця розподілу наступним чином:

1. mysqldump ваші бази даних, використовуючи параметр --no-data для створення дампів, що стосуються лише схеми.
2. Завантажте дамп, призначений лише для схеми, у майстер розподілу.
3. Перетворіть кожну таблицю у програмі дистрибутива в двигун зберігання BLACKHOLE.
4. Налаштування реплікації до розпорядника розповсюдження від майстра з реальними даними.
5. Додайте параметри (копії) копіювання do-db до /etc/my.cnf головного розповсюдження.

Для кроків 2 і 3 ви також можете відредагувати дамп, призначений лише для схеми, і замінити ENGINE = MyISAM і ENGINE = InnoDB на ENGINE = BLACKHOLE, а потім завантажити цей відредагований дамп, призначений лише для схеми, в Master Master.

Тільки на кроці 3, якщо ви хочете скриптувати перетворення всіх таблиць MyISAM і InnoDB в BLACKHOLE в Master Master, запустіть наступний запит і виведіть його в текстовий файл:

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

Додатковим бонусом до створення сценарію перетворення таблиці в механізм зберігання даних BLACKHOLE є те, що також перетворені таблиці двигуна пам'яті MEMORY . Якщо таблиця двигуна пам’яті MEMORY не займає дисковий простір для зберігання даних, вона займе пам’ять. Перетворення таблиць MEMORY в BLACKHOLE збереже пам’ять у розпорядника дистрибутива незатиснутим.

Поки ви не надсилаєте жодного DDL в Master Master, ви можете передати будь-який DML (ВСТАВКА, ОНОВЛЕННЯ, УДАЛЕННЯ), якого ви так бажаєте, перш ніж дозволити клієнтам копіювати лише інформацію про БД, яку вони хочуть.

Я вже написав публікацію на іншому веб-сайті StackExchange, де обговорюється використання магістра розподілу .

ПРЕДЛОЖЕННЯ №2: Використовуйте менші бінарні журнали та журнали ретрансляцій

Якщо ви встановите max_binlog_size на щось смішно невелике, то бінлоги можна збирати та відправляти меншими шматками. Існує також окремий варіант встановлення розміру журналів ретрансляцій, max_relay_log_size . Якщо max_relay_log_size = 0, воно буде за замовчуванням для того, для чого встановлено max_binlog_size.

ПРОПОЗИЦІЯ №3: Використовуйте напівсинхронну реплікацію (лише для MySQL 5.5)

Налаштування основної бази даних та декількох майстрів дистрибуції як MySQL 5.5. Увімкніть напівсинхронну реплікацію, щоб основна база даних могла швидко відправляти бінлоги до Master Master. Якщо ВСІ ваші раби - це мастери розповсюдження, можливо, вам не знадобиться напівсинхронна реплікація або MySQL 5.5. Якщо у будь-якого з підлеглих, крім розпорядників дистрибуції, є реальні дані для звітування, високої доступності, пасивного режиму очікування або резервного копіювання, тоді перейдіть разом із MySQL 5.5 разом із напівсинхронною реплікацією.

ПРИКЛАД №4: Використовуйте бінарний журнал на основі виписки, а не на основі рядків

Якщо оператор SQL оновлює декілька рядків у таблиці, бінарний журнал на основі звітності (SBBL) зберігає лише оператор SQL. Той самий оператор SQL, що використовує рядовий бінарний журнал (RBBL), фактично записуватиме зміну рядків для кожного рядка. Це робить очевидним, що передача операторів SQL заощадить простір у бінарних журналах, які роблять SBBL через RBBL.

Ще одна проблема - використання RBBL спільно з реплікацією do-db, де ім'я таблиці має попередньо встановлену базу даних . Це не може бути корисним для раба, особливо для магістра з розподілу. Тому переконайтеся, що у всіх DML немає баз даних та періоду перед будь-якими іменами таблиць.

Максимальний розмір max_binlog_size повинен бути неактуальним - дані бінлогів виводяться постійно.

Застереження щодо "майстра розподілу" - це "єдиний пункт відмови". Тобто, якщо він загине, всі раби (і) поза ним не отримуватимуть даних, і відновлення ретрансляції займе роботу.

SBR vs RBR - це залежить від запиту. Або може бути краще, або гірше, ніж інше.

Поставте майстри розподілу на ту ж машину, що і справжній Майстер, або на машину, "поруч" з Майстром. Використовуйте окремі порти, щоб зберегти екземпляри окремими.