|
|
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
miksoft, так с innodb просто сразу остановиться и ничего кроме репликации не грозит. тут и обсуждать нечего. можно только обсудить почему вообще никто даже не стал проектировать таких опций. myisam хотя бы один необычный вариант решения предоставляет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2015, 22:47:20 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
netwindmyisam хотя бы один необычный вариант решения предоставляет.Ну если только из спортивного интереса попытаться попробовать. Чтобы проверить как быстро битые таблицы и мусор в данных появятся. Кстати, key_buffer_size и кэш ФС тоже вырубать придется? А без кэшей что за жизнь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 10:34:13 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
miksoft, вроде нет, меняется поведение key buffer . вот я тут нагуглил старинный документ http://www.fromdual.com/sites/default/files/external_locking.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2015, 14:53:03 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
netwindИменно. Ответ на запрос обновления не вернется пользователю придет подчиненый сервер не сообщит от за принятии транзакции. Поэтому во всяких штуках реализующих распределение запросов пользователя кидают на одно и ту же ноду. Какая-нибудь хеш функция от IP или еще чего-нибудь. Да, есть задержки. Но под вебом редко подразумеваются интернет-магазины. Если за каждой покупкой стоят реальные деньги обычно нет таких проблем. Да! Прочитал. При мастер-мастер синхроне пока данные не синхронизируются на всех нодах - транзакция не закрывается. Чтение не возможно. Блин! ;-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 17:18:37 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
miksoftnetwind, Так external locking - это только для MyISAM. Я же неявно придерживаюсь версии, что будет использоваться InnoDB, раз уж мой вопрос про движок был проигнорирован. Да не игнорировал я вопрос. Просто он до такой степени детализации не дошел. Мне поровну - че скажете, то и будет! Почитаю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 17:21:47 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74Просто он до такой степени детализации не дошел.Разные движки очень по разному работают с файлами. Поэтому разговор в отрыве от конкретного движка смысла не имеет. Selen74че скажете, то и будет!Про то, что "кластер" на общих файлах никакой пользы не принесет, один вред - это мы уже давно говорим. И, видимо, не только мы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 17:33:20 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74netwindИменно. Ответ на запрос обновления не вернется пользователю придет подчиненый сервер не сообщит от за принятии транзакции. Поэтому во всяких штуках реализующих распределение запросов пользователя кидают на одно и ту же ноду. Какая-нибудь хеш функция от IP или еще чего-нибудь. Да, есть задержки. Но под вебом редко подразумеваются интернет-магазины. Если за каждой покупкой стоят реальные деньги обычно нет таких проблем. Да! Прочитал. При мастер-мастер синхроне пока данные не синхронизируются на всех нодах - транзакция не закрывается. Чтение не возможно. Блин! ;-)) Да что-то все не так вы читаете. Чтение отлично будет работать. Как и все остальное в innodb как в многоверсионной реализации транзакций. Будет замедлена отдача ответа на commit. Но я повторюсь: не зря все эти распределители нагрузки и от крутых фирм, и в линуксе, распределяют клиентские запросы предсказуемым образом. Следующий запрос придет на тот же сервер, ( если первый сервер за этот промежуток не помрет, конечно ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 18:37:32 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
netwindраспределители нагрузки и от крутых фирм, и в линуксе, распределяют клиентские запросы предсказуемым образомКстати, нынче уже и nginx умеет распределять MySQL-ные коннекты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 18:39:40 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
netwindДа что-то все не так вы читаете. Чтение отлично будет работать. Как и все остальное в innodb как в многоверсионной реализации транзакций. Будет замедлена отдача ответа на commit. Я про новые данные. netwindНо я повторюсь: не зря все эти распределители нагрузки и от крутых фирм, и в линуксе, распределяют клиентские запросы предсказуемым образом. Следующий запрос придет на тот же сервер, ( если первый сервер за этот промежуток не помрет, конечно ) Да. Я прочитал про балансировщики. Изначально я хотел вообще на ..... даже говорить не буду на чем хотел!! Даже не спрашивайте! Стыдно! Ну.... если уж очень настаиваете... RoundRobin DNS! Но это было давно! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 19:20:10 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Подводя итоги дискуссии! Так или иначе: https://ru.wikipedia.org/wiki/Oracle_RAC В частности: "Каждый дополнительный узел кластера обеспечивает дополнительные вычислительные ресурсы для обработки данных," http://habrahabr.ru/post/72122/ В частности: "... да вся статья ...." Надеюсь на этом не остановимся, а содержание моего поста, наоборот, послужит активацией мыслительного процесса и привлечения новых идей! Эти "пудели" смогли, а мы нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 19:39:41 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
miksoftnetwindраспределители нагрузки и от крутых фирм, и в линуксе, распределяют клиентские запросы предсказуемым образомКстати, нынче уже и nginx умеет распределять MySQL-ные коннекты. Умеет! Там, со стороны Веб, вообще все шикарно! Только не умеем мы читать данные из одной миски! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 19:41:47 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74Надеюсь на этом не остановимся, а содержание моего поста, наоборот, послужит активацией мыслительного процесса и привлечения новых идей! Эти "пудели" смогли, а мы нет?Эм... Мы вроде MySQL не пишем (по крайней мере, большинство из нас), чтобы "смочь". Selen74Стыдно! Ну.... если уж очень настаиваете... RoundRobin DNS! Но это было давно!И чего тут стыдиться? Вполне нормальный механизм. Его используют многие крупные порталы, включая Гугл, Яндекс и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2015, 19:53:27 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74, а нагрузка у Вас какая, сколько http запросов в секунду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2015, 00:19:34 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74Эти "пудели" смогли Что они смогли? RAC - в основном маркетинговая фича, поскольку в случаях, когда бутылочным горлышком является система ввода-вывода (а таких большинство), не только не помогает, но даже вредит. А прочие случаи (когда ноды работают с одними и теми же данными) - сводит к первому и опять же вредит. То есть это очень узкопрофильная вещь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2015, 15:06:19 |
|
||
|
Один файл базы - два (и более) сервера.
|
|||
|---|---|---|---|
|
#18+
Selen74miksoftпропущено... Кстати, нынче уже и nginx умеет распределять MySQL-ные коннекты. Умеет! Там, со стороны Веб, вообще все шикарно! Только не умеем мы читать данные из одной миски! что-то неинтересно с вами. авторNGINX Plus supports three session persistence methods. The methods are set with the sticky directive ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2015, 15:23:15 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39116094&tid=1832431]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 383ms |

| 0 / 0 |
