суть в том что на одном фронте регается юзер

а на втором его нет

А постгре рассматривался? Он как-то лучше держит репликацию

Нет, коней на переправе не меняю.

Я не готов за несколько месяцев в прод выкатывать ДБ с какоторой совсем не знаком.

за несколько месяцев?

Да.

несколько месяцев - эт с головой времени :\

Дык мне не переехать, мне с нуля вторую версию движка написать надо

бэкэнд+дба, фронтэнд спихну

Я не готов за несколько месяцев в прод выкатывать ДБ с какоторой совсем не знаком.

причем у постгреса своих камней более чем

а на втором его нет

ну и где он?

Используя опенсоурс одно из самых главных условий для меня при выборе из несколких вариантов это как можно большее комъюнити

в бинлоге на сервере где регался есть? в релей логе на слейве есть? в базе слейва есть?

ну и где он?

в астрале, наверное

искать-то в трех местах всего

больше трепу

искать-то в трех местах всего

хех

в последний раз когда я ловил такое говно

все просто

в мастерелоге последовательность была одна запросов

в рилей другая

приложухи не нужно переписывать, там тот же скуль

ну выяснил я это

и что?

последовательность запросов

можно выяснить, что мускул - дерьмина. а можно выяснить и починить

в row репликации

у меня от твоих историй собака-подозревака начинается

слушай, ты ходишь вокруг да около

я не понимаю

если бы ты видел содержимое бинлог при row репликации, то понял бы )

если бы ты видел содержимое бинлог при row репликации, то понял бы )

что понял бы?

я видел

что по нему нельзя понять в каком порядке запросы)

что по нему нельзя понять в каком порядке запросы)

т.е. ты хочшеь сказать, что запрос в строке 10 бинлог не будет выполнен раньше чем запрос в строке 100?

или что?

бинлог пишется не последовательно?

мне очень интересно

данные прост не мастер по порядку отдаёт, а аллах меняет биты прям на носителе

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

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

он может влиять на консистеность

чтоб грабли пособирать

если я сделаю insert from (select ...)

а вот содерэжимое для селекта еще ние приедет

то я поймаю лом

в репликацию

он может влиять на консистеность

в распределенной системе

Вот вычеслительную железку можно арендовать хоть целиком под себя одного, не деля ни с кем

вропрос не в том, что целиком под одну задачу, а в том, что это "целиком" всёравно виртуалка и появляются накладные расходы на любые операции.

в распределенной системе

я не понимаю, что тут у тебя под распрделенноый системой

действительно, что же это такое

Мы тратим не больше 1К$ сейчас на амазон

3 сервера за 200 баксов будут дешевле и останется на ещё одного индуса =)))

у тебя де-факто в одной точке из одного источника данные приходят с задержкой

ты физически не можешь гарантировать консистентность связей, за которую сейчас борешься

ты физически не можешь гарантировать консистентность связей, за которую сейчас борешься

но тогда мы говорим что репликация это такая хуйня которая нам ваще не гарантирует С в CAP и все

так?

что такое С в CAP?

мы уже говорили, что если ты хочешь - ты можешь использовать синхронную репликацию

или писать нормальные запросы

потому что это вот совсем не та консистеность, про которую здесь разговор идет

в insert from select еще кстати order by нужен, иначе можешь напихать че-нить в разном порядке

3 сервера за 200 баксов будут дешевле и останется на ещё одного индуса =)))

А их можно так же в любой момент подключать за пару минут и отключать, когда не надо, добавлять мощности или дискового пространства до 64ТБ на лету?

в insert from select еще кстати order by нужен, иначе можешь напихать че-нить в разном порядке

в любом случае, запросы пишу не я

отслеживать каждый запрос, который пишет разраб я тоже не могу

более того, у разраба орм там какойнеть

Consistency: Every read receives the most recent write or an error

и он сам не знает

ERROR: S client not available

Consistency: Every read receives the most recent write or an error

хуясе басню сократили

если мы берем выдержку из википедии, то нет, ваша репликация в мускуле никогда вам ничего такого не предоставит

так на кой хер лить слезы по порядку данных в репликационном логе?

Окей, подлиннее: 1. Consistency (atomic data objects) A total order must exist on all operations such that each operation looks as if it were completed at a single instance. For distributed shared memory this means (among other things) that all read operations that occur after a write operation completes must return the value of this (or a later) write operation.

поэтому у вас изначально формальная A-система (не AP, потому что после возврата сети в строй она не соберется), и вы просто занимаетесь прикладыванием подорожника к изначально неработающей штуке

ну нельзя использовать орм и мастер-мастер с которым он не умеет работать

подними уже галеру себе

хватит ругаться на инструмент, который ты используешь не для тех целей, что он плохой

в insert from select еще кстати order by нужен, иначе можешь напихать че-нить в разном порядке

Лечится MIXED/ROW

нет же

ну по крайней мере в доке про это не говорится)

Не мешайте человеку страдать :)

Ему нраится же

мне?

да я все переделал на M-S и оно почти работает

тока иногда загибается репликция, но есть перезаливка

ну по крайней мере в доке про это не говорится)

If and only if the preceding queries have no ORDER BY clause guaranteeing a deterministic order. For example, for INSERT ... SELECT with no ORDER BY, the SELECT may return rows in a different order (which results in a row having different ranks, hence getting a different number in the AUTO_INCREMENT column), depending on the choices made by the optimizers on the master and slave. A query is optimized differently on the master and slave only if: The table is stored using a different storage engine on the master than on the slave. (It is possible to use different storage engines on the master and slave. For example, you can use InnoDB on the master, but MyISAM on the slave if the slave has less available disk space.) MySQL buffer sizes (key_buffer_size, and so on) are different on the master and slave. The master and slave run different MySQL versions, and the optimizer code differs between these versions. This problem may also affect database restoration using mysqlbinlog|mysql. The easiest way to avoid this problem is to add an ORDER BY clause to the aforementioned nondeterministic queries to ensure that the rows are always stored or modified in the same order. Using row-based or mixed logging format also avoids the problem. https://dev.mysql.com/doc/refman/5.7/en/bugs.html

а ну так это надо было до конца дочитать

пф

ну то что результат ордер бай может быть разный

особенно с влюченным офсетом

это вообще не тайна

ну то что результат ордер бай может быть разный

без order by

вот у меня щас разраб один нашел запрос "с подселектом в ордере"

вот у меня щас разраб один нашел запрос "с подселектом в ордере"

Чего чего? Это как?

explain SELECT DISTINCT be.*FROM events beINNER JOIN event_tags bt ON be.id = bt.event_idINNER JOIN events be1 ON be1.id = 1038 AND be.id <> be1.idLEFT OUTERJOIN event_regions er ON be.id = er.event_idWHERE be.is_deleted = "N" AND be.state = 3ORDER BY (bt.tag_id IN (SELECT tag_idFROM event_tags bt1WHERE bt1.event_id = be1.id)) DESC, be.sort DESC, (be.age_from <= be1.age_to AND be.age_to >= be1.age_from) DESC, (be.member_type = be1.member_type) DESC, (be.type = be1.type) DESC, (be.is_external = be1.is_external) DESC, RAND()LIMIT 4

типа вот

сколько вы платите человеку, который это написал?

платили много )

скажем "нормально"

но он пхпшник )

запрос сейчас будут чинить