Я хочу створити кластер MySQL, збалансований навантаженням, але без фактичного балансира навантаження, щоб не додати ще одну крапку або складність.
Що я думав, це мати наступне:
Майте майстер-налаштування для MySQL
На кожному клієнті розмістіть простий проксі-сервер, який би обертав запити між серверами.
Чи можливо це? Або є кращі способи цього досягти?
Відповіді:
Будь ласка, прочитайте мою іншу відповідь на це питання, перш ніж реально використовувати проксі-сервер MySQL будь-якого типу. Якщо у вас є два сервери-майстри, на які пише CMS, та 10 httpd, які читають лише з нього, у вас все буде добре, але (як зазначено в іншій відповіді), це не завжди так. Вас попередили.
MySQL Proxy - це проста програма, яка сидить між вашим клієнтом та сервером MySQL, яка може контролювати, аналізувати та трансформувати їх зв’язок. Його гнучкість дозволяє необмежено використовувати; до загальних належать: балансування навантаження; відмовка; аналіз запитів; фільтрація та модифікація запитів; та багато іншого.
.
HAProxy - це безкоштовне, дуже швидке та надійне рішення, що пропонує високу доступність, балансування навантаження та проксі для TCP та HTTP-додатків
Якщо ви запустили його в режимі TCP, це може бути навіть краще, ніж Wackamole. Якби мені довелося вибирати між ними, я б використав HAProxy. Крім того, HAProxy може мати багато резервних даних, Waclamole може мати лише 2. Зауважте, що HAProxy "німий", він з'єднує сокети, не дивлячись на те, що знаходиться всередині потоку - виділений MySQL Proxy може мати можливість вказувати різні запити на вказані сервери .
Напевно, варто згадати, реплікація Galera для MySQL для справжньої установки MultiSQL MySQL. Galera - це протокол синхронної реплікації, тому програми можуть читати та записувати на будь-який із серверів MySQL. Ось короткий підручник: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial
Що стосується балансирів навантаження перед серверами MySQL, використовуйте роз'єм MySQL, який підтримує цю функціональність (наприклад, Connector / J для Java, або Mysqlnd для php)
Якщо у вас немає роз'єму, який може це зробити, тоді використовуйте щось на зразок HA-проксі. Цей скрипт автоматично налаштовує HA Proxy і підтримує список хороших серверів MySQL: https://github.com/severalnines/haproxy
З повагою,
Винай
www.severalnines.com
Реплікація master-master не настільки гарна, як ви можете подумати, те ж саме стосується проксі-сервера і подібних «легких» рішень. Якщо ви зобов’язуєтесь зіштовхувати дані на окремих серверах досить швидко (швидше, ніж затримка між серверами, яка на виробничих серверах може скласти до повної секунди *), вони приймуть дані. Якщо у вас є аукціонний сервер, ви просто продали одну і ту ж машину двічі . Хто її купив? Це залежить від того, яку БД Ви запитаєте!
Додаток повинен знати, що насправді є 2 бази даних, і він повинен знати обидві їхні IP-адреси. Якщо ви хочете "продати", вам слід подати
DB_number = `auction_number` % `number_of_databases`( %є для modulo)
... і зафіксувати його в базі даних DB_number. Якщо ви отримаєте помилку підключення, можливо, зробіть це з іншим (але у випадку аукціонного сервера я б просто відобразив помилку).
Крім того, IP-адреси повинні бути wackamole -d між обома серверами. У сценарії стихійних ситуацій, коли один сервер баз даних виходить на пару годин у піковий час використання, ви побачите, що програма намагатиметься підключитися до відсутнього сервера та зависнути до TIMEOUT, скажімо, 3 s. Раптом половина ваших запитів запускається на 3 секунди довше (і вони в кінцевому підсумку переходять в одну і ту ж базу даних - що не примушує її працювати швидше, ніж до катастрофи). Це не робить вашого httpd щасливим, оскільки він, ймовірно, має обмежений пул з'єднань одночасних обробників запитів ...
* затримка реплікації на виробничих серверах може бути до повної секунди - я перевірив це у віддаленій колокації та в нашому центрі обробки даних, і приблизно як 99% часу це 0, але іноді mysql показує 1s. У масовому трафіку у мене було багато зіткнень через те, що клієнтська програма зробила два запити, що призвело до двох запитів, вставлення та вибору. У деяких випадках рядок просто ще не було , тому ми використовували хеш userID і це вирішило проблему
Я сподіваюся, що ви дізнаєтесь з моїх помилок ;-)
Збалансований навантаженням кластер баз даних MySQL (або якийсь інший) є досить марним. Якщо ви пишете на більш ніж один сервер, ви зіткнетеся з проблемою або використовуєте синхронну реплікацію (яку MySQL так чи інакше не підтримує), і це шкодить продуктивності, оскільки це потрібно для синхронізації блокування.
Я рекомендую розділити навантаження для читання / запису та збалансувати навантаження серед прочитаних файлів між mysql-рабами, або мати єдиного мастера для запису, або використовувати активну / пасивну пару відмов для свого господаря.
По суті, ви не можете масштабувати записи, розміщуючи більше серверів у базі даних, як рабів, оскільки кожен все ще повинен записати всю завантаженість вашої програми.
Щоб масштабувати записи, вам потрібно логічно розділити свої дані на декілька серверів, розділити їх або "заточувати" тощо. Зазвичай для цього потрібні нетривіальні (думаю, що це дуже важко перевірити) зміни у вашій програмі, тому ви не хочете робити цього, якщо ви НЕ РЕАЛЬНО потрібно це.
Звичайно, ви можете використовувати кластер MySQL, якщо дуже хочете, але це зовсім інший двигун зі своїми особливостями та недоліками - налаштувати його досить складно, але дійсно забезпечує базу даних з товарним обладнанням, збалансовану навантаженням. Він все ще страждає від покарань за виконання записів від використання синхронної реплікації, але дозволяє масштабувати записи так, як це було вбудовано в розділ на серверах.
Ще одне чудове керівництво з цього приводу я знайшов ...
http://www.dancryer.com/2010/01/mysql-circular-replication
Це частина 1 із трьох публікацій серії:
Посібник з кластером збалансованого навантаження MySQL - Частина 1 - налаштування самих серверів та налаштування реплікації MySQL.
Посібник з уравновешеним кластером MySQL - Частина 2 - створив сценарій для моніторингу стану ваших вузлів кластера MySQL, який ми використаємо в наступному посібнику для налаштування нашого проксі.
Посібник з навантаженим збалансованим завантаженням MySQL - Частина 3 - налаштування балансира навантаження за допомогою HAProxy, використовуючи сценарії моніторингу
Особисто кращим способом було б використовувати балансир навантаження!
Так, це додає ще одну крапку, але будь-яка рутина, яку ви встановите або встановите на ВСІЙ клієнт, додає набагато більше складності, ніж у стандартного балансира навантаження ....
Connector / J має можливість завантажувати баланси запитів на декілька серверів. Це в першу чергу призначено для кластера MySQL NDB, де всі вузли SQL матимуть послідовне уявлення про дані, але якщо ви можете переконатися, що база даних двох майстрів буде достатньо узгоджена між цими двома майстрами, це може бути безпечним для вашої програми.
Рядок підключення виглядатиме приблизно так:
jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000
Розщеплення записів не зніме завантаження серверів, оскільки записи все одно повинні бути повторені.
Якщо ви використовуєте лише 2 сервери, використовуйте серцебиття з drbd, і дозвольте drbd обробляти реплікацію. Якщо перший сервер виходить з ладу, другий сервер бере на себе. Якщо ви хочете поставити другий сервер на використання, ви можете використовувати gfs через drbd, а потім запустити другий сервер лише для читання та використовувати його як сервер читання. Коли відбувається відмова, то змініть сервер на читання / запис.
re: wackamole - wackamole не обмежується двома серверами
Я працюю над серією підручників, яка висвітлює це, але налаштувати це дуже просто.
Для того, щоб дати більш пізню відповідь на це питання, з версією 5.6 MySQL було представлено GTID (Global Transaction Identifieres), який має на меті зробити асинхронну реплікацію більш надійною і знову поставити MySQL в гонку за HA (High Availability).
Цей розділ пояснює реплікацію на основі транзакцій за допомогою глобальних ідентифікаторів транзакцій (GTID). Використовуючи GTID, кожну транзакцію можна ідентифікувати та відстежувати, оскільки вона здійснена на вихідному сервері та застосовується будь-якими рабами; це означає, що при використанні GTID не потрібно посилатися на файли журналів або позиції в цих файлах під час запуску нового підлеглого або переходу на новий головний майстер, що значно спрощує ці завдання. Оскільки реплікація на основі GTID повністю ґрунтується на транзакціях, визначити, чи послідовні господарі та раби; до тих пір, поки всі транзакції, вчинені на господаря, також здійснюються на рабі, послідовність між ними гарантується. Ви можете використовувати реплікацію на основі оператора або на основі рядків з GTID (див. Розділ 16.2.1, "Формати реплікації"); проте для найкращих результатів,
Довідка: 16.1.3 Реплікація з глобальними ідентифікаторами транзакцій (MySQL Документація)
Я подумав, що використання HAProxy для запитів врівноваження - це введення SPOF (Single Point Of Faure), і додавання серцебиття робить це рішення громіздким.
Більш простим рішенням є підключення через з'єднувач Java JConnector, який спрямований на завантаження запитів балансу через URL-адресу jdbc з усіма вузлами MySQL. Він може працювати з налаштуваннями master / slave або master / master .
Це дає можливість налаштувати рішення кластеру HA з вікна за допомогою MySQL.