1. bigint — это костыль и у него есть ряд неприятностей, описанных в доке.
2. впринципе решение, если добавить условие, что нод не может быть больше 65535. (ограничение на кол-во нод: 2^32)
> Ну и что будет? select выберет все нужные id (помните, на втором сервере они тоже не удалены?), а потом удалит каждый запросом, который пойдет на оба сервера сразу.
правильно! он выберет только то что было на первом… он не выберет то что добавилось на втором, т.к. со второго на первый еще не отреплецировалось! И следовательно не удалит то, что добавилось на втором. Такую же схему можно и обрисовать и с обратной стороны — не удаления, а добавления…
> вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
не судите о других — они не знали, что вы новичек в репликации и будете проводить эксперименты на них, поэтому не оптимизировали приложения под master-master репликацию. в этом думаю не было вины программеров. в этом вина безголового админа, который элементарно не может понять понятия асинхронности.
дальнейшее обсуждение бесполезно, т.к. ответ на ваш вопрос я дал, а дальнейшие ваши утверждения только говорят о ваших ошибках в понимании технологии.
> Если делать репликацию на уровне sql запросов, а не данных, то задержка с получением данных от второго сервера будет равнозначна тому, что второй админ просто чуть позже нажал кнопку удаления.
утешайте себя этим :)
если запрос на удаление чайлдов такой: DELETE FROM childs WHERE parent=ParentID; — то да, проблем не будет, а если удаление происходит так: SELECT * FROM childs WHERE parent=ParentID; и потом в цикле DELETE FROM childs WHERE ID=ChildID; (это кстати нормальный вариант ООП подхода) — то проблемы будут (мусор останется).
> посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
а теперь посчитайте, сколько там было ИЗМЕНЕНИЙ в одной сущности в секунду и поймете, что вам просто повезло, что проблем не возникало или вам просто не сообщили о проблеме или не обнаружили ее.
В ваших доводах нет доказательств. Я же вам вполне четко доказал возможность нарушения целостности.
en.wikipedia.org/wiki/CAP_theorem
вот есть хорошая теоремка. в ней популярно раписано как и что работает и почему нельзя достичь идеала. даже доказана эта теорема :)
ОДИН СЕРВЕР:
два варианта алгоритма:
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет.
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу. (в это случае будет мусор).
ДВА СЕРВЕРА:
опять два варианта алгоритма:
предположим, что данные с того сервера, где заходил другой админ еще не дошли до того сервера, с которым работаете вы, а это вполне возможно в схеме репликации.
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет. (в данном случае в любом случае добавит, т.к. в вашей версии базы этот родитель еще не удален).
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу.
и только потом приходит репликация на второй сервер, на котором работает вы и удаляет то, что было у этого родителя до того, как вы нажали чего-то там не важно что…
в случае двух серверов в любом случае будет мусор.
Мусора не будет только в том случае, если дети удаляются так DELETE FROM childs WHERE parent=ParentID; — но это возможно только в том случае если у этих детей нет своих детей или по какой-то другой причине (поэтому я и говорю, что тут все очень сильно зависит от реализации приложения).
пардон конечно, но это вы не вникли в ответ, ибо ответ на ваш вопрос там дан:
Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются Асинхронно и это надо учитывать при написании приложения.
в случае одного сервера тут все отработает нормально.
непредсказуемая ошибка (зависит от того как это обрабатывает конечное приложение), в данном случае joomla. Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются не Асинхронно и это надо учитывать при написании приложения.
Joomla скорее всего на это не расчитана.
вообщем и целом просто брать любой сайт и так распределять — глупо.
я перепутал название опции. я имел ввиду auto_increment_increment.
я не сталкивался с этим и всячески буду этого избегать.
вот пример:
у вас стоит auto_increment_increment=2
1. на node1 добавляют запись. ID=1
2. на node2 добавляют запись. ID=2
3. на node2 добавляют запись. ID=4
4. на node2 добавляют запись. ID=6
4.5. все отреплецировалось…
5. вы меняете increment на 3 на node1
6. на node1 добавляют запись. ID=7. auto_increment=10
7. репликация от п.6. еще не прошла на node2.
8. на node2 добавляют запись. ID=8. auto_increment=10
9. репликация от п.6. еще не прошла на node2.
10. на node2 добавляют запись. ID=10. auto_increment=12
11. на node1 добавляют запись. ID=10. auto_increment=13
12. вы меняете increment на 3 на node2
13. репликация от п.6 и п.11 пришла на node2 и репликация встает из-за Duplicate key.
как решать данную проблему? я решения не знаю… подскажите — буду только рад :)
решение останавливать все ноды менять настройку и запускать все ноды обратно меня не устраивает в силу объективных причин, Особенно, если инстанс мускула стартует несколько минут.
Может в последних версиях мускула этот как-то изящно решается, но я не слышал.
забавно будет посмотреть на те позы из камасутры, в которые вам прийдется вставать, чтобы увеличить кол-во mysql нод больше чем первоначально заданное вами значение auto_increment_offset :)
не безопасно, с точки зрения атаки…
лучше своеим чередом без воздействия снаружи выгребать из очереди (ящика) письма в порядке их поступления и обрабатывать во столько потоков, сколько ваш сервер физически может вытянуть.
мыслите шире. только на слоганах что-ли все остановилось.
можно просто попросить ввести какое-то слово изображенное где-то на банере. или выделенное чем-то… и т.д. и вперемешку иногда отдавать и стандартную капчу.
тоже тишина. шумит только вентилятор блока питания и дешевый большой вентилятор, который установлен на Cooler Master сверху на всякий случай (шумит, т.к. близко к стенке установлен)
Без вентилятора Core 2 Duo E7400 работал стабильно, но я решил не рисковать и поставил вентилятор…
смотрю, уже модификацию сделали: Cooler Master GeminII S
Единственная засада в этих больших радиаторах — не в каждый корпус влезет… у меня в один корпус он влез (остался зазор 1-2 мм между радиатором и блоком питания), а вот, в другом упирался БП :(
я думаю, что имея контактные данные покупателя:
1. через 1-2 недели после покупки связываться с покупателем и спрашивать у него обратную связь.
2. отправлять на почту письмо с текстом «вы тогда то покупали у нас такой крутой товар, не хотели бы вы поделиться мнением о нем?» + какие-нить еще наводящие вопросы и возможно тут же предлагать бонусы, как написано в топике.
PS: мне лично всегда приятно, когда после обращения к дилеру где-то через неделю-две мне звонят и просят оценить качество услуг.
а какая должна быть на ваш взгляд реакция Яндекса на данное событие?
у них такое происходит по несколько раз на день скорее всего… и это обыденность.
PS: я тут как то наблюдал картину, как чувак в маршрутке по телефону пытался объяснить как набрать тот пароль, который он установил на комп. объяснял как надо двигаться по клавиатуре, но при этом не называл буквы… начиная с третьей буквы я уже не выдержал и продиктовал ему пароль… «qazwsx» тот удивился и повторил его в трубку… :)
Согласен полностью!
писать просто X-Forwarder-For глупо и бессмыслено.
Скрипт, определяющий айпи-адрес входящего, был перенаправлен на самого себя и поэтому определил свой адрес.
это че в яндексе такие приложения пишут? я конечно много раз встречал от сотрудников яндекса такие глупые отписки, но чтобы такую отровенную чушь… жесть.
Однако у нас хранится информация обо всех айпи-адресах, с которых совершаются платежи
ну и собственно вопрос назревает сам: почему этот же IP и не показывать пользователю? Зачем придумывать какой-то хитрый скрипт, который в итоге сам себя обманывает?
Сам прокси-сервер также хранит информацию о том, с каких адресов были заходы на него, и получить эту информацию также сможет милиция.
как показывает практика, если прокси зарубежные, то никто уже этим не занимается.
2. впринципе решение, если добавить условие, что нод не может быть больше 65535. (ограничение на кол-во нод: 2^32)
правильно! он выберет только то что было на первом… он не выберет то что добавилось на втором, т.к. со второго на первый еще не отреплецировалось! И следовательно не удалит то, что добавилось на втором. Такую же схему можно и обрисовать и с обратной стороны — не удаления, а добавления…
> вообще подход быдлокодерский, но какой уж есть, чужой код на то и чужой.
не судите о других — они не знали, что вы новичек в репликации и будете проводить эксперименты на них, поэтому не оптимизировали приложения под master-master репликацию. в этом думаю не было вины программеров. в этом вина безголового админа, который элементарно не может понять понятия асинхронности.
дальнейшее обсуждение бесполезно, т.к. ответ на ваш вопрос я дал, а дальнейшие ваши утверждения только говорят о ваших ошибках в понимании технологии.
утешайте себя этим :)
если запрос на удаление чайлдов такой: DELETE FROM childs WHERE parent=ParentID; — то да, проблем не будет, а если удаление происходит так: SELECT * FROM childs WHERE parent=ParentID; и потом в цикле DELETE FROM childs WHERE ID=ChildID; (это кстати нормальный вариант ООП подхода) — то проблемы будут (мусор останется).
> посещаемость была достаточная для того, чтобы проблемы могли вылезти (несколько десятков тысяч хостов и суммарно порядка миллиона хитов в сутки).
а теперь посчитайте, сколько там было ИЗМЕНЕНИЙ в одной сущности в секунду и поймете, что вам просто повезло, что проблем не возникало или вам просто не сообщили о проблеме или не обнаружили ее.
В ваших доводах нет доказательств. Я же вам вполне четко доказал возможность нарушения целостности.
вот есть хорошая теоремка. в ней популярно раписано как и что работает и почему нельзя достичь идеала. даже доказана эта теорема :)
ОДИН СЕРВЕР:
два варианта алгоритма:
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет.
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу. (в это случае будет мусор).
ДВА СЕРВЕРА:
опять два варианта алгоритма:
предположим, что данные с того сервера, где заходил другой админ еще не дошли до того сервера, с которым работаете вы, а это вполне возможно в схеме репликации.
1. программа проверяет родителя к которому вы хотите сохранить ваш документ и выдает ошибку если его нет, если есть — добавляет. (в данном случае в любом случае добавит, т.к. в вашей версии базы этот родитель еще не удален).
2. программа не проверяет наличие родителя, к которому вы хотите сохранить ваш документ и тупо добавляет в базу.
и только потом приходит репликация на второй сервер, на котором работает вы и удаляет то, что было у этого родителя до того, как вы нажали чего-то там не важно что…
в случае двух серверов в любом случае будет мусор.
Мусора не будет только в том случае, если дети удаляются так DELETE FROM childs WHERE parent=ParentID; — но это возможно только в том случае если у этих детей нет своих детей или по какой-то другой причине (поэтому я и говорю, что тут все очень сильно зависит от реализации приложения).
Доступно написал?
Если в момент удаления радздела, выбираются и удаляются все его дети, то в этом случае на сервере, где узер что-то добавлял, это что-то останется мертвым грузом. (опять же зависит от того как написать приложение).
это называется нарушена целостность. данные обновляются Асинхронно и это надо учитывать при написании приложения.
в случае одного сервера тут все отработает нормально.
это называется нарушена целостность. данные обновляются не Асинхронно и это надо учитывать при написании приложения.
Joomla скорее всего на это не расчитана.
вообщем и целом просто брать любой сайт и так распределять — глупо.
я не сталкивался с этим и всячески буду этого избегать.
вот пример:
у вас стоит auto_increment_increment=2
1. на node1 добавляют запись. ID=1
2. на node2 добавляют запись. ID=2
3. на node2 добавляют запись. ID=4
4. на node2 добавляют запись. ID=6
4.5. все отреплецировалось…
5. вы меняете increment на 3 на node1
6. на node1 добавляют запись. ID=7. auto_increment=10
7. репликация от п.6. еще не прошла на node2.
8. на node2 добавляют запись. ID=8. auto_increment=10
9. репликация от п.6. еще не прошла на node2.
10. на node2 добавляют запись. ID=10. auto_increment=12
11. на node1 добавляют запись. ID=10. auto_increment=13
12. вы меняете increment на 3 на node2
13. репликация от п.6 и п.11 пришла на node2 и репликация встает из-за Duplicate key.
как решать данную проблему? я решения не знаю… подскажите — буду только рад :)
решение останавливать все ноды менять настройку и запускать все ноды обратно меня не устраивает в силу объективных причин, Особенно, если инстанс мускула стартует несколько минут.
Может в последних версиях мускула этот как-то изящно решается, но я не слышал.
лучше своеим чередом без воздействия снаружи выгребать из очереди (ящика) письма в порядке их поступления и обрабатывать во столько потоков, сколько ваш сервер физически может вытянуть.
можно просто попросить ввести какое-то слово изображенное где-то на банере. или выделенное чем-то… и т.д. и вперемешку иногда отдавать и стандартную капчу.
ссылка на описание Cooler Master Gemin II
тоже тишина. шумит только вентилятор блока питания и дешевый большой вентилятор, который установлен на Cooler Master сверху на всякий случай (шумит, т.к. близко к стенке установлен)
Без вентилятора Core 2 Duo E7400 работал стабильно, но я решил не рисковать и поставил вентилятор…
смотрю, уже модификацию сделали: Cooler Master GeminII S
ссылка на описание Cooler Master Gemin II S
Единственная засада в этих больших радиаторах — не в каждый корпус влезет… у меня в один корпус он влез (остался зазор 1-2 мм между радиатором и блоком питания), а вот, в другом упирался БП :(
1. через 1-2 недели после покупки связываться с покупателем и спрашивать у него обратную связь.
2. отправлять на почту письмо с текстом «вы тогда то покупали у нас такой крутой товар, не хотели бы вы поделиться мнением о нем?» + какие-нить еще наводящие вопросы и возможно тут же предлагать бонусы, как написано в топике.
PS: мне лично всегда приятно, когда после обращения к дилеру где-то через неделю-две мне звонят и просят оценить качество услуг.
у них такое происходит по несколько раз на день скорее всего… и это обыденность.
PS: я тут как то наблюдал картину, как чувак в маршрутке по телефону пытался объяснить как набрать тот пароль, который он установил на комп. объяснял как надо двигаться по клавиатуре, но при этом не называл буквы… начиная с третьей буквы я уже не выдержал и продиктовал ему пароль… «qazwsx» тот удивился и повторил его в трубку… :)
писать просто X-Forwarder-For глупо и бессмыслено.
это че в яндексе такие приложения пишут? я конечно много раз встречал от сотрудников яндекса такие глупые отписки, но чтобы такую отровенную чушь… жесть.
ну и собственно вопрос назревает сам: почему этот же IP и не показывать пользователю? Зачем придумывать какой-то хитрый скрипт, который в итоге сам себя обманывает?
как показывает практика, если прокси зарубежные, то никто уже этим не занимается.
оспаривать гениальность кожуальных и социальных игр я ни в коем случае не собираюсь :)
С удовольствием бы поучаствовал в каком-нить явно успешном проекте технической стороной ;)