MySQL Кластеризация
Доброго времени суток. Хотел бы прояснить некоторые вопросы связанные с MySQL кластеризацией.
1. В кластере MySQL из 2,3...серверов все сервера работают одновременно, или работает главный сервер и в случае его падения стартует альтернативный?
2. Если одновременно работаю все севера MySQL в кластере, значит ли это что происходит распределение нагрузки на все сервера в кластере? Что гарантирует распределение этой нагрузки? (Мыслю по аналогии с Hardware NLB [имея 2,3... WEB кластер распределением нагрузки занимается NLB сервер, сами web сервера в кластере нагрузку не разделяют])
3. Очевидно что если все севера MySQL в кластере работают одновременно, то фалы БД и журнал транзакций должны храниться на внешней системе хранения данных(что бы БД была доступна все mySQL серверам). Или же БД хранятся на MySQL серверах по отдельности но синхронизируется между собой по аналогии с данными на дисками в RAID массиве(примерное описание)?
4. Как осуществляется масштабирование кластера для увеличения производительности? Добавлением допольнительных mySQL серверов в кластер или нужна модернизация СХД? Что в большей степени влияет на производительность из выше перечисленного?
5. Как осуществлять резервирование БД из СХД без потери производительности, на отдельный раздел в самой СХД или желательно поставить отдельную СХД например на основе ленточных носителей?
6. Какой компьютер в сети должен заниматься резервированием БД (я с ноутбука подключаюсь к кластеру и запускаю процесс резервирования или это желательно делать по расписанию средствами кластера, или отдельный сервер должен делать это что бы не нагружать производительность кластера [это для меня не ясно пока!])?
Всем огромное спасибо за понимание и ответы.
С уважением и наилучшими пожеланиями Руслан.
Subject
Views
Written By
Posted
MySQL Кластеризация
6240
November 14, 2012 07:36AM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.