20:00:04 От Александр Филиппенко : + 20:00:04 От Dmitriy Shitikov : + 20:00:05 От Михаил : + 20:00:08 От Alexey U : + 20:00:08 От Alexey Kryachko : + 20:01:26 От Andy : Некоторые пользователи покупают Mac, потому что круто и ставят Windows, потому-что удобно. 20:01:49 От Vitaly Yushkevich : + 20:01:49 От Kirill Amurskiy : + 20:01:52 От Михаил : + 20:01:52 От Alexey Kryachko : + 20:01:53 От Александр Филиппенко : + 20:01:53 От Andy : + 20:01:53 От Dmitriy Shitikov : + 20:01:56 От Анатолий : + 20:03:43 От Kirill Amurskiy : - 20:03:45 От Dmitriy Shitikov : - 20:03:59 От Vitaly Yushkevich : Не по плану занятия, но есть какой-то срок по давним вопросам по индексу? ) Можно просто дату сегодня назвать :) 20:04:33 От Vitaly Yushkevich : По физике 20:05:21 От Kirill Amurskiy : -+ 20:05:23 От Vitaly Yushkevich : + 20:05:23 От Alexey U : - 20:05:29 От Alexey Kryachko : -+ 20:05:29 От i.perov : + 20:05:32 От Александр Филиппенко : -+ 20:05:33 От Eugene Ermakov : - 20:05:33 От Dmitriy Shitikov : -+ 20:05:35 От Ivan Danilov : - 20:05:40 От Alexander Bogushov : - 20:08:38 От Kirill Amurskiy : что то смутно 20:08:46 От Vitaly Yushkevich : Для реплики же (в том числе)? 20:08:59 От Kirill Amurskiy : надо как то более четко, какой журнал, в каком порядке, что пишется, что пишется в таблицы и т.д. 20:09:04 От Dmitriy Shitikov : у меня эхо что-то 20:09:14 От Александр Филиппенко : да 20:09:15 От Dmitriy Shitikov : да, все равно 20:09:16 От Eugene Ermakov : + 20:09:21 От Alexey U : Да, это из-за помещения 20:11:58 От Alexey U : А что если в журнал не записалось? 20:12:18 От Kirill Amurskiy : Что происходит по шагам после комманды Commit? 20:12:59 От Kirill Amurskiy : ну я имею в виду как фиксируется транзакция по шагам 20:13:28 От Kirill Amurskiy : ну в смысле с точки зрения журналов, таблиц и т.д. 20:13:30 От Vitaly Yushkevich : А rollback делается как? 20:14:46 От Kirill Amurskiy : Давайте разберем работу начиная с Открытия транзакции, потом изменение таблицы, потом закрытие транзакции. Что происходит, в каком порядке, что в таблице, что в журналах и т.д. 20:16:54 От Kirill Amurskiy : А если мы ее изменили, мы сразу пишем в журналы? 20:19:05 От Kirill Amurskiy : применилась/не применилась 20:19:12 От Alexey U : 2 исхода 20:20:34 От Alexey U : да 20:20:50 От Kirill Amurskiy : да, если мы специальные финты накрутим 20:21:10 От Vitaly Yushkevich : А это мы сейчас не про CAP теорему говорим? 20:21:12 От Kirill Amurskiy : в стиле, перед подтверждением хотя бы на одну дополнительную ноду скопируем результат 20:21:36 От Kirill Amurskiy : ну транзакция 20:25:24 От Alexey U : Лаг 20:25:46 От Vitaly Yushkevich : повторное выполнение? 20:25:57 От Александр Филиппенко : обрыв сети во время ответа? 20:26:42 От Kirill Amurskiy : ну так с async тоже самое 20:26:45 От Kirill Amurskiy : ? 20:26:46 От Vitaly Yushkevich : Это фантомные записи в том числе? 20:27:08 От Sergey : это acid ограничение? 20:28:16 От Kirill Amurskiy : а как в реальности поступают с тем, что есть некоторое время рассинхрона между мастером и слейвами? Забивают? 20:29:40 От Kirill Amurskiy : отвалился экран 20:30:05 От Vitaly Yushkevich : + 20:30:08 От Kirill Amurskiy : + 20:30:10 От OTUS Онлайн-образование : http://yoshinorimatsunobu.blogspot.com/2014/04/semi-synchronous-replication-at-facebook.html 20:30:25 От OTUS Онлайн-образование : https://www.percona.com/live/19/sites/default/files/slides/MySQL%20Replication%20and%20HA%20at%20Facebook%20-%20Part%202%20-%20FileId%20-%20187303.pdf 20:30:57 От OTUS Онлайн-образование : https://www.percona.com/community-blog/2018/08/23/question-about-semi-synchronous-replication-answer-with-all-the-details/ 20:32:00 От Aleksey : повышенная надежность в ущерб скорости? 20:32:06 От Kirill Amurskiy : + 20:32:10 От Sergey : А можете про применение типов синхронизаций рассказать? 20:35:36 От Vitaly Yushkevich : + 20:35:43 От Kirill Amurskiy : групповая репликация? 20:35:49 От Sergey : Банковские операции, которые не терпят потери транзакций асинхронные? 20:35:56 От Kirill Amurskiy : а что с групповой? 20:36:29 От Kirill Amurskiy : ок 20:37:11 От Kirill Amurskiy : а какой порядок времения для MySQL? 20:39:48 От Kirill Amurskiy : запросы на изменение? 20:39:54 От Kirill Amurskiy : угу 20:41:24 От Александр Филиппенко : А тарантул куда? 20:42:05 От Kirill Amurskiy : Тарантул-MySQL - это кроссСУБД репликация? 20:45:09 От Kirill Amurskiy : а в рамках одной транзакции можно? 20:45:31 От Kirill Amurskiy : при вставке в MySQL хочется получить id свежевставленной записи 20:45:58 От OTUS Онлайн-образование : last_inserted_id 20:46:06 От Sergey : А касательно сети между репликами есть какие то особенности? 20:46:09 От Kirill Amurskiy : ну это в рамках одной транзакции мы выполняем select после insert 20:47:22 От Kirill Amurskiy : ну т.е. insert потом select last_id - это норм? 20:47:31 От Kirill Amurskiy : В рамках одного вызова БД 20:47:57 От Ivan Danilov : INSERT ... SELECT? 20:48:02 От OTUS Онлайн-образование : insert_to_master(); 20:48:09 От OTUS Онлайн-образование : select_from_slave(); 20:48:33 От Kirill Amurskiy : ну то, чем занимаются все каждый день: вставляю запись и надо вернуть пользователю, что вставили 20:48:51 От Kirill Amurskiy : А как делать тогда? 20:49:20 От Dmitriy Shitikov : а в транзакции используется всегда одно подключение? припоминаю что у mssql есть distributed transaction, правда насколько это надежно работает... 20:51:19 От Kirill Amurskiy : ну так это разве не то, о чем я писал выше insert …; select last_id; ? 20:51:31 От Kirill Amurskiy : Это вроде соответствует обоим приведенным стратегиям сразу. 20:52:01 От Kirill Amurskiy : почему 950? 20:52:16 От Kirill Amurskiy : так я же выполняю select на мастере 20:52:44 От Kirill Amurskiy : там не нужно получить id вставленной записи после вставки 20:52:51 От Kirill Amurskiy : *мне 20:53:34 От Александр Филиппенко : а кто рулит тем куда идут запросы, а куда селекты? Приложение, или бывают прослойки которые это разрулят? 20:54:36 От Vitaly Yushkevich : А как обычно делают для примера «не соц сеть"? 20:54:38 От Александр Филиппенко : да 20:54:54 От Kirill Amurskiy : ну вроде можно читать last_id после вставки, как я понял 20:55:38 От Vitaly Yushkevich : Админ может новость добавить, можно агрегацию забирать из других rss 20:56:45 От Vitaly Yushkevich : Тоже :) А статистику / counter из редиса 20:57:53 От Alexey Kryachko : Анализируем где клиент больше читает, отправляем на слейв, там где клиент может модифицировать шлем на мастер 20:58:44 От Kirill Amurskiy : а в каком нибудь ВК или Facebook чтение своих данных создает огномную нагрузку как можно подумать 20:59:02 От Kirill Amurskiy : тут шардирование? 20:59:28 От Kirill Amurskiy : норм 21:00:53 От Kirill Amurskiy : а как этого добиваются? какая-то функция от userId, которая возвращает Id слейва? 21:01:30 От Александр Филиппенко : Как VShard у тарантула? 21:02:37 От Alexey U : Слей упал 21:02:48 От Kirill Amurskiy : баллансировка нагрузки? 21:03:13 От Kirill Amurskiy : по алгоритму консистентного кэша 21:05:29 От Kirill Amurskiy : а как так может произойти? 21:05:35 От Kirill Amurskiy : не ясно при чем здесь шардирование 21:06:08 От Kirill Amurskiy : ясно 21:06:40 От Kirill Amurskiy : ну это из-за странного подхода к шардированию, кажется, что если нормально шардирование организовывать, такого быть не должно 21:07:24 От Анатолий : + 21:07:26 От Aleksey : - 21:07:28 От Александр Филиппенко : + 21:07:29 От Ivan Danilov : - 21:07:29 От Sergey : - 21:07:30 От Vitaly Yushkevich : ± 21:07:33 От Dmitriy Shitikov : +- 21:07:36 От Михаил : + 21:09:06 От Sergey : Ну это же внутри mysql не на уровне приложения? 21:09:42 От Vitaly Yushkevich : а B в этом случае будет слать C «ты потерял транзакцию»? Или пока не поднимется A? Или мы получим рассинхрон? 21:10:13 От Vitaly Yushkevich : А как это «фиксится»? 21:11:15 От Kirill Amurskiy : как С может стать мастером, если он старее, чем Б? 21:11:17 От Vitaly Yushkevich : я не про «конфликт идентификаторов». Если можно, еще раз про рассинхрон из-за падения мастера и как они потом становятся снова консистенции (хотя бы с течением времени) 21:11:35 От Kirill Amurskiy : (* facepalm *) 21:12:39 От Sergey : расскажите про критерии выбора сервера для реплики? Понятно что можно у того же хостера, но может есть какие то особенности, как это на практике делают 21:12:51 От Vitaly Yushkevich : Round robin? 21:13:35 От Kirill Amurskiy : а мастер где? 21:13:43 От Kirill Amurskiy : хммм 21:13:58 От Sergey : на уровне приложения определять географию? 21:13:59 От Kirill Amurskiy : А у Facebook как интересно? 21:14:05 От Kirill Amurskiy : шардирование по географии 21:14:22 От Kirill Amurskiy : угу 21:14:27 От Dmitriy Shitikov : а между дц (тем более географически удаленными) репликация же будет с отставанием? и синхронную (полусинхронную) не сделать? 21:16:24 От Vitaly Yushkevich : А «перекаливаем» - это повторный прогон через bin log? 21:16:29 От Vitaly Yushkevich : переналивем* 21:17:00 От Kirill Amurskiy : а это возможно разве? Ведь новый мастер уже уехал далеко? 21:17:06 От Sergey : А практически это как делается? 21:17:06 От Vitaly Yushkevich : А если этот мастер «потерялся», и часть транзакций дошла до части слейвов? 21:18:01 От Vitaly Yushkevich : Мы выбираем новый мастер, но у него нет части транзакций. (И Бин лога) 21:18:35 От Sergey : всмысле если мастер упал, заходим на сервер реплики и перестраиваем его на слей? 21:18:42 От Vitaly Yushkevich : То есть, если на слейве не выполнилась транзакция, то гарантированно у нас есть бинлог? 21:18:45 От Kirill Amurskiy : так вот не понятно, зачем тогда перенакатывания бин лога? 21:18:51 От Vitaly Yushkevich : И мы можем след алгоритм: 21:18:55 От Vitaly Yushkevich : - меняем его на мастера 21:19:01 От Vitaly Yushkevich : - перегоняем бинлог 21:19:06 От Vitaly Yushkevich : Получаем гарантированное состояние 21:19:26 От Vitaly Yushkevich : А выше обсуждали, если мы взяли не самый свежий слейв? 21:19:46 От Sergey : А как перегнать бинлог? 21:20:18 От Vitaly Yushkevich : То есть нельзя брать не самый свежий слейв? 21:20:22 От Sergey : так мастер же упал 21:20:58 От Sergey : понятно 21:21:01 От Sergey : попробую 21:21:14 От Vitaly Yushkevich : Если мы взяли не самый свежий слейв, то мы можем потерять часть данных? 21:21:51 От Vitaly Yushkevich : А вот вопрос - как ее потом устранить? 21:21:55 От Kirill Amurskiy : т.к. запись должна быть сразу во все мастеры 21:22:06 От Vitaly Yushkevich : понял, спасибо 21:25:17 От Sergey : Ну то есть купят билет на одно и тоже место 21:26:02 От Sergey : Понял, на уровне приложения 21:26:10 От Sergey : супер 21:26:34 От Vitaly Yushkevich : А это же похоже на шардинг? Или это другое? 21:27:59 От Sergey : Если он не встречается зачем его изучать? 21:28:16 От Sergey : + 21:29:26 От Vitaly Yushkevich : Одновременная запись в слейвы? 21:29:26 От Sergey : определить кто первый 21:29:29 От Kirill Amurskiy : нельзя быть уверенным, что то что ты записал записалось 21:29:30 От Vitaly Yushkevich : (Неразличимо) 21:30:00 От Sergey : Второй обидется 21:30:13 От agapov : может быть рассинхрон времени 21:30:20 От Alexey Kryachko : потерянные данные? 21:30:24 От agapov : + задержка 21:31:20 От Sergey : Ну это еще Эйнштейн рассказывал) 21:35:17 От Kirill Amurskiy : - 21:35:28 От Sergey : - 21:35:32 От Dmitriy Shitikov : - 21:37:28 От Kirill Amurskiy : что такое r и w 21:37:30 От Kirill Amurskiy : ? 21:38:15 От Kirill Amurskiy : не совсем 21:38:23 От Kirill Amurskiy : а как это на этапе выполнения работает? 21:38:49 От Kirill Amurskiy : угу 21:39:33 От Kirill Amurskiy : аааа, ясно 21:39:36 От Sergey : А как же те у которых запись не прошла? 21:39:59 От Sergey : они уже все потом совсем не учавствуют? 21:40:07 От Sergey : + 21:41:08 От Sergey : + 21:41:10 От Kirill Amurskiy : а зачем такая репликация? для производительности она только вредит 21:41:25 От Vitaly Yushkevich : а там данные не расползаются со временем? 21:42:03 От Kirill Amurskiy : чтобы гарантировать, что более чем в половине данные добавились 21:42:10 От Kirill Amurskiy : *половине нод 21:42:36 От Александр Филиппенко : но тогда успешное чтение будет со всех нод 21:43:10 От Александр Филиппенко : + 21:43:16 От Kirill Amurskiy : более менее 21:43:27 От Vitaly Yushkevich : То есть любой запрос всегда идет на чтение с нескольких нод? 21:43:43 От Vitaly Yushkevich : r 21:43:51 От Dmitriy Shitikov : а как определится самое свежее из трех? 21:43:55 От Kirill Amurskiy : раз эта репликация не вредит производительности, значит она повышает производительность? 21:44:21 От Kirill Amurskiy : а на производительность типа не влияет? 21:45:24 От Kirill Amurskiy : ясно 21:45:27 От Vitaly Yushkevich : А как это внутри выглядит? Условно, мы пишем select * from users where id = 1; Дальше под капотом идет запрос на все ноды, в возвращаемом результате есть версия результата. Это сравнивается по r нодам, чтобы была максимальная версия и отдаем этот гарантированный результат (максимальная версия у не менее чем r нод?) 21:46:58 От Eugene Ermakov : как определить самые свежие? 21:47:02 От Kirill Amurskiy : успешно имеется в виду, что они доступны и отвечают 21:47:03 От Dmitriy Shitikov : и самые свежие выберутся уже по версии? 21:47:06 От Dmitriy Shitikov : т.е. конечный результат 21:47:07 От Vitaly Yushkevich : То есть «если хотя бы r нод вернуло хоть что-то, то берем последнюю версию и возвращаем"? 21:49:05 От Vitaly Yushkevich : А для какого класса систем / задач такой подход (бд) подходят лучше? (Например, относительно того же mysql) 21:49:40 От Kirill Amurskiy : для блокирабельных систем) (привет Роскомнадзор) 21:49:58 От Sergey : Этот подход чисто уровень приложения? 21:54:47 От Kirill Amurskiy : + 21:54:58 От Vitaly Yushkevich : осознаю. Можно еще раз? 21:56:37 От Vitaly Yushkevich : + 21:56:38 От Sergey : + 21:59:16 От i.perov : Следующее занятие по плану в среду? 21:59:17 От Vitaly Yushkevich : безусловно 21:59:23 От Sergey : Очень полезно, спасибо! 21:59:33 От i.perov : Спасибо, интересно. 21:59:41 От Vitaly Yushkevich : А можно книгу в slack кинуть? 21:59:48 От Vitaly Yushkevich : Спасибо 21:59:50 От Alexey Kryachko : Еще вопрос Вы рассказывали, что люди строят слушателей реплик и прослушивая их делают консюмеров 21:59:56 От Alexey Kryachko : Почему не системы очередей? 22:00:02 От Alexey Kryachko : Так быстрей? 22:00:04 От Kirill Amurskiy : т.е. мы организуя корзину на сервере храним все "изменения", которые вносят муж с женой, а при отображении корзины vs "накатываем" все изменения на карзину и отображаем? 22:00:41 От Eugene Ermakov : А мы будем в будущем проходить конфигурирование mysql в каком-нибудь виде? 22:00:41 От Kirill Amurskiy : а почему не просто все изменения хранить? 22:00:43 От Sergey : а можно пояснить про гит и мастер мастер, разве это распределенная база данных? 22:00:52 От Kirill Amurskiy : тогда проще алгоритм выглядит 22:01:45 От Vitaly Yushkevich : Если останется время, можно еще раз по физическому хранению составных индексов и полнотекстовому поиску? 22:01:56 От Vitaly Yushkevich : Полнотекстовым индексам* 22:02:03 От Sergey : А это именно гитхаб 22:02:06 От Sergey : понял 22:02:43 От Sergey : Поесть можно его организовать вне гитхаба? 22:02:53 От Vitaly Yushkevich : Git init 22:03:05 От Vitaly Yushkevich : Дальше git add remote 22:03:33 От Vitaly Yushkevich : Болит :) 22:05:10 От Vitaly Yushkevich : ага, я правильно понимаю, допустим A кодируется 11, B - 22, то в B-tree будет хранится таким образом: 22:05:19 От Vitaly Yushkevich : AABB: 11112222 22:05:33 От Vitaly Yushkevich : сейчас :) 22:05:41 От Vitaly Yushkevich : Допустим у нас есть ключ 1 22:06:03 От OTUS Онлайн-образование : uint8 22:06:22 От OTUS Онлайн-образование : 0X01, 0x05 22:06:52 От Vitaly Yushkevich : а если значение первого индекса в кортеже «меньше», то оно заполняется нулями слева, условно? 22:07:20 От Vitaly Yushkevich : То есть размер индекса всегда фиксированный. Условно, первая часть индекса - всегда фиксированный набор байт? 22:07:38 От Vitaly Yushkevich : у меня было сомнение, допустим есть индекс 22:07:42 От Vitaly Yushkevich : (AA; BB) 22:07:47 От Vitaly Yushkevich : И (AAB; B) 22:07:51 От Vitaly Yushkevich : условно индексы 22:08:22 От Vitaly Yushkevich : Допустим индексы 22:08:40 От Vitaly Yushkevich : У нас составной индекс - это кортеж 22:08:45 От Vitaly Yushkevich : со значениями 22:08:54 От Vitaly Yushkevich : допустим составной индекс по двум столбцам 22:09:25 От Vitaly Yushkevich : Соответственно, указание на индекс по кортежу состоит из двух частей, первая часть - это индекс первой части 22:10:00 От Vitaly Yushkevich : вот я правильно понял сейчас, что если размер первой части меньше, то он все равно заполняет всю выделенную часть? 22:10:18 От Kirill Amurskiy : лучше голосом Виталий 22:12:19 От Kirill Amurskiy : а если строка на первом месте, то как будет склейка? 22:12:41 От Kirill Amurskiy : ну там символ конца строки 22:12:53 От Kirill Amurskiy : мне кажется сначала строка сравинвается, потом все остальное 22:13:21 От OTUS Онлайн-образование : if (a1 != a2) return a1>a2 22:13:31 От OTUS Онлайн-образование : else (b1 != b2) return b1 > b2 22:13:57 От OTUS Онлайн-образование : else return c1-c2; 22:16:42 От Vitaly Yushkevich : Все, спасибо большое 22:16:47 От Dmitriy Shitikov : спасибо 22:16:47 От Kirill Amurskiy : спасибо