Перейти к содержанию
melihovgv

Репликация мастер слейв на 1.5.5.1 настройка?

Рекомендуемые сообщения

Добрый день!

Репликация мастер слейв на 1.5.5.1 как настроить опенкарт?

Настроит mysql master-slave - все работает

Добавил подключение в index.php

http://prntscr.com/i9wqsl

и /home/admin/web/any-tool.ru/public_html/system/library/db.php

http://prntscr.com/i9wr6x

http://prntscr.com/i9wrap

 

После этих манипуляций нет подключения к базе. 

Помогите советами?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Репликацию настраивайте на уровни сервера. Нечего трогать PHP библиотеки движка

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 час назад, melihovgv сказал:

Добрый день!

Репликация мастер слейв на 1.5.5.1 как настроить опенкарт?

Настроит mysql master-slave - все работает

Добавил подключение в index.php

http://prntscr.com/i9wqsl

и /home/admin/web/any-tool.ru/public_html/system/library/db.php

http://prntscr.com/i9wr6x

http://prntscr.com/i9wrap

 

После этих манипуляций нет подключения к базе. 

Помогите советами?

 

Тут у меня вопрос - зачем и еще раз зачем?

Что касается настройки репликации - вы это делаете из примера с ruhihgload. И это большая глупость.

 

Если уж очень сильно хочется. То настройте репликацию баз. Поставьте HaProxy как балансировщик и будет вам счастье.
Если не хочется заморачиваться с HaProxy, механизм репликации и балансировки есть их коробки в php 

http://php.net/manual/ru/book.mysqlnd-ms.php

 

А если хотите совсем заморочится - попробуйте galera cluster  и maxscale.


Но все эти механизмы актуальны только для большой, оооочень большой нагрузки. Так например opencartforum, на котором вы это читаете в секунду обрабатывает  десятки тысяч запросов, а пиковая мощность системы сотня-полторы тысяч запросов mysql в секунду. 

Я таких магазинов не видел. Даже магазины с трафиком 25-30 000 посетителей в день генерируют на порядок меньше. 


Если вы таким образом пытаетесь поднять производительность магазина - то сначала надо привести в порядок сами запросы и их количество. А репликация и шардинг - это механизмы горизонтального масштабирования, которые приходят на помощь в случае, если вертикальное масштабирование упирается в предел мощности одного сервера.

 

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Quote

Но все эти механизмы актуальны только для большой, оооочень большой нагрузки. Так например opencartforum, на котором вы это читаете в секунду обрабатывает  десятки тысяч запросов, а пиковая мощность системы сотня-полторы тысяч запросов mysql в секунду. 

 

Это необходимо реализовать для автоматической обработки прайс листов

При обновлении / добавлении товара мастер отдает 504...На слейв не переключается.

Примерно 5-7 прайсов раз в два дня обновляется / добавляется...По времени сайт висит от 8 до 12 часов.

Поисковики этого не любят.

 

 

Изменено пользователем melihovgv

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 hours ago, Yoda said:

Если вы таким образом пытаетесь поднять производительность магазина - то сначала надо привести в порядок сами запросы и их количество. А репликация и шардинг - это механизмы горизонтального масштабирования, которые приходят на помощь в случае, если вертикальное масштабирование упирается в предел мощности одного сервера.

 

Магазин с 40.000 товара, работает шустро.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 часов назад, melihovgv сказал:

 

Это необходимо реализовать для автоматической обработки прайс листов

При обновлении / добавлении товара мастер отдает 504...На слейв не переключается.

Примерно 5-7 прайсов раз в два дня обновляется / добавляется...По времени сайт висит от 8 до 12 часов.

Поисковики этого не любят.

 

 

 

innodb + innodb_flush_log_at_trx_commit = 2 + глубокая оптимизация базы + нормальная разгрузка системы + полное отключение кеширования в mysql сервере и никакой репликации. Это самый примитивный и простой механизм. Если вы будете городить репликацию на неоптимизированной системе для таких задач. То все ляжет еще больше, не забывайте что синхронизация - это тоже ресурсоемкая задача. Необходимо проверить и минимизировать количество индексов на таблицах, их формирование и перестроение  - та еще задача. Также не забывайте, про кеши. Про  тот же кеш сео про, который обновляется нон стоп каждый раз при добавлении каждого товара, перегенерация которого тоже отжирает много ресурсов. И здесь нужно еще копать в сторону отключения в нем кеширования. 

Т.е. просто поверьте - у вас проблема не в базе а в глобальной настройке системы, что в 90% случаев можно решить "неинвазивными методами". 

 

Что касается нетривиального решения этой задачи, если бы я ее решал для себя я бы сделал совершенно по другому.  Я бы сделал клон базы, исключительно с таблицами товаров, парсил бы товары в клон. И примитивным крон-скриптом раз в час синхронизировал сводными запросами напрямую из базы в базу актуализированные товары. Как то по принципу. Отключили front на 10 секунд. Или не отключили, а поставили на паузу, или отдаете готовый html-кеш, а по результатам апдейта сбрасываете. А потом как то INSERT IGNORE INTO front_base.oc_product SELECT * FROM parse_base.oc_product, либо еще быстрее через TRUNCATE  parse_base.oc_product, INSERT ... SELECT * FROM....


Если вам не требуются какие то супер-реал-тайм апдейты цен-наличия с поставщика, то в любом случае кумулятивное обновление всего набора данных с каким то временным интервалом - будет эффективнее чем атомарные апдейты. 

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
14 hours ago, Yoda said:

 

innodb + innodb_flush_log_at_trx_commit = 2 + глубокая оптимизация базы + нормальная разгрузка системы + полное отключение кеширования в mysql сервере и никакой репликации. Это самый примитивный и простой механизм. Если вы будете городить репликацию на неоптимизированной системе для таких задач. То все ляжет еще больше, не забывайте что синхронизация - это тоже ресурсоемкая задача. Необходимо проверить и минимизировать количество индексов на таблицах, их формирование и перестроение  - та еще задача. Также не забывайте, про кеши. Про  тот же кеш сео про, который обновляется нон стоп каждый раз при добавлении каждого товара, перегенерация которого тоже отжирает много ресурсов. И здесь нужно еще копать в сторону отключения в нем кеширования. 

Т.е. просто поверьте - у вас проблема не в базе а в глобальной настройке системы, что в 90% случаев можно решить "неинвазивными методами". 

 

Что касается нетривиального решения этой задачи, если бы я ее решал для себя я бы сделал совершенно по другому.  Я бы сделал клон базы, исключительно с таблицами товаров, парсил бы товары в клон. И примитивным крон-скриптом раз в час синхронизировал сводными запросами напрямую из базы в базу актуализированные товары. Как то по принципу. Отключили front на 10 секунд. Или не отключили, а поставили на паузу, или отдаете готовый html-кеш, а по результатам апдейта сбрасываете. А потом как то INSERT IGNORE INTO front_base.oc_product SELECT * FROM parse_base.oc_product, либо еще быстрее через TRUNCATE  parse_base.oc_product, INSERT ... SELECT * FROM....


Если вам не требуются какие то супер-реал-тайм апдейты цен-наличия с поставщика, то в любом случае кумулятивное обновление всего набора данных с каким то временным интервалом - будет эффективнее чем атомарные апдейты. 

 

 

 

 

 

Ок...

А если настроить связку haproxy + репликация мастер мастер(в сети примеры ) и отдавать через haproxy /admin серверу, который будет занят добавлением / обновлением товаров. Тем самым одна машина будет разгружена?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
50 минут назад, melihovgv сказал:

Ок...

А если настроить связку haproxy + репликация мастер мастер(в сети примеры ) и отдавать через haproxy /admin серверу, который будет занят добавлением / обновлением товаров. Тем самым одна машина будет разгружена?

 

Любая репликация из двух узлов - по умолчанию ненадежна и подвержена коллизиям. 

Для стабильной работы необходима система хотя бы 1M + 2S + Advisor. 
Теоретически, возможно частично вы снимите ваши проблемы. Но получите на выходе еще больше проблем чем у вас сейчас связанных с мониторингом, стабильностью, рассинхронами этого огорода.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.