Репликация мастер слейв на 1.5.5.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

 

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

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

[Yoda]

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 посетителей в день генерируют на порядок меньше. 

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

 

[melihovgv]

Quote

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

 

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

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

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

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

 

 

Змінено 5 лютого 2018 користувачем melihovgv

[melihovgv]

21 hours ago, Yoda said:

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

 

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

[Yoda]

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....

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

 

 

 

 

 

[melihovgv]

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 серверу, который будет занят добавлением / обновлением товаров. Тем самым одна машина будет разгружена?

[Yoda]

50 минут назад, melihovgv сказал:

Ок...

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

 

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

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