Про 20к интересно, это на Galera или обычная репликация? Просто у нас уже при всплесках до 1-2к начинает расти очередь на отправку. При этом трафик сети в районе нескольких мегабит, есть мнение, что дело не в пропускной способности, а в latency сети.
Скорость записи ограничивается двумя параметрами: диском и сетью. С дисками у нас проблем нет, они могут сильно больше, чем у нас есть сейчас (сейчас 400-600 qps, диски могут вытянуть 40-60к). Сейчас ограничивающим фактором является сеть (1 Gbit/s), по ощущениям через нее можно пропихнуть 1.5-2к qps. Сеть планируем апгрейдить.
По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
Все горячие данные помещаются в память, чтение с диска минимальное, в районе 100-200 IOPS. Да, большие выборки активно кэшируются, на nosql бд приходит около 30к rps. Из MySQL в основном делаются простые выборки по Primary Key для тех данных, которые нежелательно или не нужно кэшировать. Постоянно обновляется кэш и работают кроны, которые используют напрямую БД без кэша.
Если репликация всё равно асинхронная, то в чем принципиальная разница для разработчика разъедутся ноды на 10 или 1000 транзакций?
Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.
По каким причинам в рассмотрение не попал MySQL NDB Cluster?
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
Вы абсолютно правы, репликация все равно асинхронная и думать все равно приходится. Разница в том, что у нас например длина очереди 173 транзакции, это примерно 0.5 сек отставания при больших транзакциях (округлим до секунды). Разработчик может быть уверен, что измененные данные окажутся на слейве через секунду. В случае обычной асинхронной репликации никаких гарантий нет и слейв может отставать например на пол часа. Хотя на корню это проблему конечно не решает, это не настоящая синхронная репликация.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
По тестам от Percona MaxScale медленнее ProxySQL в fast-forward режиме процентов на 10-20%. Учитывая это и то, что нам важна задержка мы решили не тестировать его. В итоге ProxySQL тоже не прошел по задержкам оставив первенство Haproxy. Если у вас есть информация о том, что сейчас ситуация изменилась и MaxScale может обогнать ProxySQL, то мы с удовольствием протестируем его скорость работы.
У нас уже был опыт использования продуктов от Percona, причем вполне успешный. Нас устраивает их скорость выпуска багфиксов и портирования патчей из апстрима. К тому же они русскоязычные и продают поддержку. Если нам понадобится помощь всегда можно купить у них поддержку их продукта.
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
master-master обязан считать транзакцию завершенной только тогда, когда ее совершили все ноды
Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
Противоречит, никто и не спорит. Но если бы все всё делали по логике и здравому смыслу, то мы бы жили в абсолютно другом мире. И не надо думать, что я считаю рабочих дураками, а капиталистов умниками, все они в первую очередь люди. А люди далеко не самые рациональные существа.
Как пример — распад СССР, куча работающих заводов была продана частным лицам, казалось бы даже инвестировать в производство не надо, оно уже у тебя есть. Надо только поддерживать его на плаву и получать постоянный доход с него. Но нет, большинство заводов было закрыто и распродано или разворовано, часть на все тот же металлолом.
Или например все знают, что алкоголизм/наркотики/курение ведут к болезням и возможно скорой смерти, но почему то кучу людей это не останавливает.
Вы сами говорите, что средства производства должны быть в собственности рабочего. Только станок с неба не упадет. Чтобы дать возможность рабочему работать за ним его сначала надо купить, а захочет ли рабочий вкладывать 2-10М рублей в станок, чтобы потом отбивать его стоимость 10 лет?
Есть конечно вариант отобрать станки у злобных капиталистов и раздать рабочим, но к чему то хорошему это вряд ли приведет. Скорее всего станки сдадут на металлолом.
ИМХО сейчас общественный строй достаточно сбалансирован, у тех же рабочих есть возможность уйти работать на завод получше к менее «эксплуатирующему» капиталисту. А если так уж не хочется работать на дядю, то открывать ИП и свое производство. Вот только со своим предприятием приходит куча проблем, никакой гарантированной зарплаты, рабочий не может весь день производить полезный продукт, а вынужден делать тысячу других дел, таких как бухучет, продажа товара, закупка сырья, реклама и тд.
И тут выглядит логичным следующий шаг — делегировать эти обязанности кому то другому и нанять их на зарплату. Oh wait, мы же вернулись к началу, только уже рабочий стал капиталистом.
Офф гарантия — 3.6 перезаписи всего объема накопителя (500 Гб) в день в течение 5 лет. У нас нагрузка должна быть сильно меньше, до 500 Гб в день. С такой нагрузкой скорее контроллер умрет, чем выработается ресурс.
Интересная статья, спасибо. А не могли бы вы посчитать (среднюю, и 95/99 перцентиль) скорость износа SSD с разбиением на серверные и консьюмерские модели?
Тот же хецнер грешит тем, что ставит в дешевые сервера десктопные SSD, причем самые дешевые. У нас их десктопные SSD живут примерно пол года с репликами БД, а ентерпрайзные самсунги уже по 2.5 года работают и умирать не собираются.
а что делать, если туда надо постоянно лазить, править, ну и конечно же нет лога всех действий, не писать же каждый раз cp cfg cfg_back, со временем запутаешься и забьешь на это дело.
Конфиг Haproxy в Ansible, Ansible в гит. И никаких проблем с версионированием изменений. Плюс без проблем разливается на кучу серверов.
Для сбора статистики — экспортер в Prometheus, откуда можно вытягивать данные в Grafana и строить красивые графики.
Ваш подход без сомнения имеет право на жизнь, но по моему описанное выше больше соответствует UNIX-way, т.к. легче масштабируется до десятков-сотен серверов и очень легко умеет в автоматизацию. Накрутить дополнительной логике в Ansible дело нескольких минут, на крайний случай часов, и вот у вас уже есть например авто дискавери бэкендов или автоматическое указание веса бэкенда в зависимости от количества процессорных ядер на нем и все остальное, что вы только сможете придумать. ;)
Касательно GPLv2 — вам стоит прочитать ее внимательно. Согласно лицензионному соглашению исходные тексты обязаны быть предоставлены людям, получившим бинарники системы, тем или иным способом.
Да, я это знаю. Как раз про это была эта часть моего вопроса:
… нужно ли для этого быть вашим клиентом?
Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
Вы пишите о своих наработках на базе KVM. Отправляете ли вы эти патчи в апстрим и принимают ли их? Можно ли где то у вас на сайте их получить/скачать и нужно ли для этого быть вашим клиентом?
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
С шумом все более-менее нормально, большинство времени кулер выключен. При запуске чего то тяжелого и длительного, например компиляции большого проекта, начинает активно шуметь. Проц прогревается до 78-84 градусов.
Использую ядро 4.16.9, дистрибутив Arch, дрова «xf86-video-intel 1:2.99.917+831+ge7bfc906-1». Проблем из-за 4К пока не видел, но не исключаю, что это из-за свежих версий софта, который я использую. Специально брал ноут только со встройкой Intel, что бы не парится с проприетарными дровами нвидии и не править их глюки.
На просторах интернета куча текстовых и видео обзоров с качественными фото со всех ракурсов, анбоксингом и прочими радостями. Я решил, что вряд ли сделаю обзор внешности ноутбука лучше, чем они и решил сосредоточиться на функциональной части.
Я использовал 175% процентное масштабирование чтобы уменьшить интерфейсы ПО, по мне они часто занимают слишком много места на экране. Таким образом увеличивается размер полезной области экрана.
Ну и конечно качество шрифтов сильно улучшилось, на FullHD 13-ке были заметны отдельные пиксели, с 4к пикселей не видно вообще.
По масштабированию на уровне кластер — если понадобится вероятно будем шардировать на уровне приложения на несколько кластеров.
Важно то, что мы знаем на сколько они могут разъехаться, рассчитывать на константу проще. Подробнее ответил в комментарии выше.
Честно говоря не помню, почему то исключили его из рассмотрения в самом начале поисков решения.
Еще можно использовать переменную «wsrep_sync_wait=7». Это заставит ноду выполнить запрос только после применения всех транзакций в текущей очереди.
Как я уже писал отказоустойчивость это основная причина внедрения кластера у нас. Но защищены только те транзакции, которые успели реплицироваться на остальные ноды. При внезапном падении сервера могут быть потерянные транзакции.
Во-вторых у них есть некоторые патчи на Galera Cluster, которые делают его поддержку более простой (например strict_mode, который не даст выполнить потенциально опасные операции на кластере).
Я не уверен как реализовано в MariaDB Galera, но в классическом Galera Cluster и Percona GC это не так. Каждая транзакция валидируется на всех нодах при коммите на отсутствие конфликтов, а репликация самих изменений выполняется уже после коммита.
Как пример — распад СССР, куча работающих заводов была продана частным лицам, казалось бы даже инвестировать в производство не надо, оно уже у тебя есть. Надо только поддерживать его на плаву и получать постоянный доход с него. Но нет, большинство заводов было закрыто и распродано или разворовано, часть на все тот же металлолом.
Или например все знают, что алкоголизм/наркотики/курение ведут к болезням и возможно скорой смерти, но почему то кучу людей это не останавливает.
Есть конечно вариант отобрать станки у злобных капиталистов и раздать рабочим, но к чему то хорошему это вряд ли приведет. Скорее всего станки сдадут на металлолом.
ИМХО сейчас общественный строй достаточно сбалансирован, у тех же рабочих есть возможность уйти работать на завод получше к менее «эксплуатирующему» капиталисту. А если так уж не хочется работать на дядю, то открывать ИП и свое производство. Вот только со своим предприятием приходит куча проблем, никакой гарантированной зарплаты, рабочий не может весь день производить полезный продукт, а вынужден делать тысячу других дел, таких как бухучет, продажа товара, закупка сырья, реклама и тд.
И тут выглядит логичным следующий шаг — делегировать эти обязанности кому то другому и нанять их на зарплату. Oh wait, мы же вернулись к началу, только уже рабочий стал капиталистом.
Тот же хецнер грешит тем, что ставит в дешевые сервера десктопные SSD, причем самые дешевые. У нас их десктопные SSD живут примерно пол года с репликами БД, а ентерпрайзные самсунги уже по 2.5 года работают и умирать не собираются.
Конфиг Haproxy в Ansible, Ansible в гит. И никаких проблем с версионированием изменений. Плюс без проблем разливается на кучу серверов.
Для сбора статистики — экспортер в Prometheus, откуда можно вытягивать данные в Grafana и строить красивые графики.
Ваш подход без сомнения имеет право на жизнь, но по моему описанное выше больше соответствует UNIX-way, т.к. легче масштабируется до десятков-сотен серверов и очень легко умеет в автоматизацию. Накрутить дополнительной логике в Ansible дело нескольких минут, на крайний случай часов, и вот у вас уже есть например авто дискавери бэкендов или автоматическое указание веса бэкенда в зависимости от количества процессорных ядер на нем и все остальное, что вы только сможете придумать. ;)
Да, я это знаю. Как раз про это была эта часть моего вопроса:
Многие просто выкладывают исходники в открытый доступ, но не будучи вашим клиентом я не могу требовать их у вас.
И QEMU и ядро Linux, частью которого является KVM, публикуются под GPLv2, соответственно исходники должны быть;).
Вообще по характеристикам ноут почти копия Вашего Asus, если он у вас уже есть вы не выиграете в производительности от замены его на делл.
Использую ядро 4.16.9, дистрибутив Arch, дрова «xf86-video-intel 1:2.99.917+831+ge7bfc906-1». Проблем из-за 4К пока не видел, но не исключаю, что это из-за свежих версий софта, который я использую. Специально брал ноут только со встройкой Intel, что бы не парится с проприетарными дровами нвидии и не править их глюки.
Ну и конечно качество шрифтов сильно улучшилось, на FullHD 13-ке были заметны отдельные пиксели, с 4к пикселей не видно вообще.