Кто-то может назвать установку агентов недостатком, но для меня - преимущество. Особенно тогда, когда невозможно (причин может быть много, от ошибка конфигурации в ssh до банального зависания) подключиться по ssh. Очень много раз спасало именно наличие minion: просто отдаешь ему команду на выполнение. Да, не всегда с первого раза, но в данном случае уже есть установленное соединение по которому можно отправить команду. Не нужно делать новое сетевое подключение, не нужно ждать согласование cipher'ов и прочего.
Опять же. Если у вам "дешевле" отправить сервер в reboot, то salt проигрывает ansibl'y, но если сервер крайне не желательно перезагружать, и иметь дополнительную возможность подключения - преимущество у salt'a.
Это покажет список Minions, которые пытаются подключиться к Master. Для подтверждения ключа Minion юзаем:
sudo salt-key -A
На самом деле это не совсем так. ключ "-L" покажет список всех ключей, которые разбиты на несколько категорий: одобреные (Accepted), ожидающие (Unaccepted), заблокированные (там 2 вида: Rejected/Denied). Так вот, только ожидающие будут соответствовать "которые пытаются подключиться к Master".
Теперь про сам ключ "-A". Я бы не рекомендовал его использовать, так как он автоматически принимает все ключи. Лучше для этого использовать конструкцию " salt-key -a '*' " и salt покажет какие ключи будут добавлены и спросит "добавить?". Иногда бывает, что кто-то хочет добавить какой-то тестовый однодневный docker-контейнер. Не нужно забывать еще о некоторой особенности salt-stack: не активные ключи нужно время от времени удалять, так как они влияют на выполнение batch'евый заданий (когда применяется к группе). К примеру, у вас задание salt -G roles:DNS state.sls dns_prod и, если у вас хотя бы один мертвый ключ с ролью DNS, вы будете ожидать возврата терминала 60 секунд (by default), не смотря на то, что все minion'ы уже вернули статус выполнения stat'a. Поэтому, я за то, что бы не слепо "принимать" все ключи, а еще раз перепроверять, что принимать. Хотя, кому как удобнее.
В целом неплохо, но явно в докладе отчётливо прослеживается идея — я делаю именно так. А все остальные методы плохие и почти вся статья посвящается тому, что бы найти проколы в остальных методах. Особенно странно звучит фраза про использование репликации mysql и кучей проблем, которые это в себе таит. У себя использую базы в продакшине, которые связаны master-master репликацией. И это не какие-то там разовые запросы на изменения записей в DNS (ну пускай у вас будет запись в базу с rate — 10 rps/s), а реальный высоконагруженный проект с сотнями rps/s. Может просто у вас не вышло грамотно настроить репликацию и разобраться во всех её тонкостях?
Более того, с появлением GTID-репликации, проблем стало гораздо меньше (да, она чуть сложнее, да, есть нюансы, но всё это нивелируется с её преимуществами по сравнению с обычной).
Есть вопрос, в первую очередь, автору (а так же всем остальным, кто его использовал) касательно SO_REUSEPORT. AFAIK, у вас linux. Так вот, как вы увидели, что REUSEPORT у вас действительно используется (снижение нагрузки не в счёт, так как на это может влиять что угодно)? Каким механизмом? Например, во FreeBSD это можно посмотреть через procstat, а в linux'e как (перелопатил много чего, но кроме того, как это пихать в код не нашёл; ещё нашёл как-то патч от 2013 года для netstat'a, но это как-то костыльно)?
Вы забыли самые главные моменты:
— owncloud очень жутко тормозит, и упора в железо или кеширования нет. как это победить — неясно. Пробовал и памяти доставлять и opcache/memcache тюнить по параметрам, толку 0. гугление вообще не даёт толковых советов, кроме как «включите opcache/memcache»
— onlyoffice тоже не работает нормально. По крайней мере при попытке открыть через него doc/xls ругается. гугление, так же не помогает.
ну, то есть, продукт nextcloud из разряда монстров, которые написаны абы как.
В общем, я вижу, что вы уходите от прямых ответов, поэтому спорить тут бессмысленно. У вас всё сводится к тому, что «не было, не должно быть и это должно мониториться и т.д.». Вы должны быть готовы к любым ситуациям, и, если конкретная БД этого не умеет или это будет очень и очень сложно — то зачем её использовать под эти задачи изначально?
То, что вы назвали, это реально и полезно, кому-то другому, но не DBA. Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать. Экономию денег посчитаете во время сбоя DB и сроков её восстановления.
Если мне нужно будет писать много-много данных с большой-большой скоростью, то это точно не должна быть mysql, ибо она для этого не годится. Тут или NoSQL выбирать или искать другие решения. И да, я выбираю по принципу: для каждой задачи должна быть DB максимально ей отвечающая. То есть я НЕ буду пихать везде MY, потому что она мне больше симпатизирует. Если объективно она туда не подходит — то зачем её там использовать? Доказать, что что-то может работать на MY? Смысл?
Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов. Нигде нет супер-пупер скорости отдачи страниц, особенно, когда идут какие-то оплаты. Вы можете ждать и 5 и 10 секунд, и это нормально. Нет, я не говорю о каких-то минутах. Им надёжнее отдать вам страницу позже, чем потом разбираться с тем, у кого сколько денег пропало. Это если вы говорите об экономии больших денег. Я на 99% уверен, что у них oracle, но даже в этом ключе они не стремятся к быстродействию ради милисекунд.
1. Костыль, потому что это стороннее ПО, так же как и bucardo. У нормальной DB давно такие инструменты должны быть нативные.
2. Да, можно многими способами, но процент успешной миграции в моём случае был очень невелик. Зачем мне переписывать код, если дело в конкретном exten'e? Это глупо и неправильно. Правильно было бы во время дампа указать его, что есть такой exten и лежит там-то. Но нет, как ни подсовывал ему, ему всё не нравилось. Это первый пример. Второй пример, это функция digest из стандартного exten'a pgcrypto (он правда не подключён по умолчанию, но ведь это не должно быть проблемой при дампе). Итого, исходя из ваших слов, или не пользоваться вообще exten'aми, ибо всё, что не включено по дефолту сломается при обновлении, либо каждый раз переписывать код. Зачем тогда вообще нужны такие exten'ы, которые создают больше проблем чем профита?
3.
4. Пускай хоть 15-ая. Скажите, что из этих 4-ох пунктов имеет Postgres на текущий момент, не смотря на то, что у mysql это уже как несколько лет есть? Или назовите, чем он лучше для DBA в плане обслуживания и что имеет такого, чего нет в mysql и оно реально крутое? Я сейчас не про 100500 разных индексов, а про то, что реально может быть полезно.
Вы опять всё клоните в сторону разработчика, а не DBA. DBA в первую очередь волнует как это можно масштабировать, обновить, бэкапить и потом восстановить. То, что запросы будут выполняться быстрее или медленнее, это уже второй вопрос. Да, анализатор запросов в PQ лучше, чем в mysql, тут не спорю, но ради этого менять БД — сомнительно.
Mysql может нормально работать на HighLoad, главное правильно «приготовить». Зачем mysql? Затем, что его проще и надёжнее обслуживать.
Тут хочется вспомнить анекдот про работу пожарным: «На работе хорошо и бесплатно кормят, есть бесплатная спецодежда, можно поспать в рабочее время, хороший коллектив, но когда пожар — хоть увольняйся».
Кстати, пока писал коммент, вспомнил, что для mysql есть percona toolkit, который имеет ну очень полезную фичу, которая пару раз очень выручала: сделать консистентной реплику. То есть, предположим, что в одной из реплик часть данных пропали (как, это неважно: либо кто-то случайно удалил, либо по ошибкам не дошли, либо реплика долго была отключена, либо...). Как досинкать только недостающие данные, например, на 100Гб таблице, при этом, учитывая то, что в этот момент идёт репликация? Если для postgres'a есть такое же, я за него буду только рад.
Ещё раз повторюсь для всех, меня интересует сравнение PQ и MY ТОЛЬКО в плане DBA.
Неправда.
Если случился обычный crash, то данные восстанавливаются в 99% автоматически. Если так случилось, что не удалось, а это бывает крайне редко, то есть метод опция innodb_force_recovery=6, в которой база поднимается в режиме RO, неважно, насколько убита InnoDB. Можно сделать дамп, даже пропустив сбойные (если например, на диски появились bad block'и) строки, это проверенный факт.
PS. Да, в версии 5.1 (но это было ого-го когда, тогда и PQ наверное от простого ребута мог завалиться) это было часто, но тогда движок InnoDB только был в зародыше. Начиная с 5.5, это успех восстановления был уже на уровне 90%, а в 5.6 он достиг уже 99%.
Когда говорят, что Postgres крут, это говорят с точки зрения программиста или DBA? Если с точки зрения программиста, то да, там фич значительно больше. Но вот с точки зрения DBA — postgres явно не лучше.
1) Репликация.
Чего стоит мучительная репликация, которая в mysql появилась, лет, наверное 10 назад, причём не тупо «всё реплицировать», а выбирать, какие базы, таблицы. Да, в postgres'e были всякие костыли типа slony, и даже в 9-ке появилась родная binary-репликация (и да, всё так же «все реплицировать») в одну сторону (на тот момент в mysql уже давно была master-master). Вроде бы в 10-ке появилась logical, где уже можно выбирать, что реплицировать. Да, это прорыв, но почему так поздно? С тех пор я перестал следить за PQ. Я не знаю, может в 12 появилась уже master-master репликация, тогда шансы уровнялись в этой части. А может PQ умеет реплицироваться сразу с нескольких источников? mysql такое умеет, как минимум года 3.
2) upgrade с версии на версию.
Это страшный сон всех PQ DBA, даже если версии минорные, особенно, если у тебя есть custom'ные exten'ы. Ну вот нельзя просто поставить новую версию, запустить скрипт upgrad'a и всё. И это mysql умеет очень давно. Но PQ до 9.Х включительно не имел такого инструмента. Как дела в PQ в 12-ой версии — я не знаю, возможно, спустя много лет, что-то появилось.
3) recovery table
Если таблица очень большая и дамп по каким-то причинам долго переносить/делать, то можно с рабочего сервера сделать копию файла ibd (если InnoDB) потом через DISCARD/IMPORT можно «подключить» таблицу в работающую базу. Тут успех, где-то 70%, но всё-равно не малый.
4) 32-ух битный номер транзакций. Это боль для высоконагруженных БД. Такое случается очень редко, но когда случилось — это катастрофа. Как чинить — непонятно (была статья на хабре, где писали за деньги патч под это дело). Вроде бы в 10 или 11 он уже 64-их битный, но что делать было раньше? Надеятся, что ты никогда с таким не столкнёшься?
Это самые большие проблемы, с которыми приходилось мириться (и надеятся, что они никогда не настанут) и мы перешли на mysql. Были ещё мелкие недочёты, но они несущественны.
Вы могли бы мне назвать причины, в чём PQ лучше MY, как для DBA?
Если я не так сравниваю, укажите, где именно я ошибся. Расскажите, как правильно сравнивать.
Хм, экономическая часть вас не устраивает, здоровье — тоже. Ну ок.
Мне кажется, что экономическая выгода будет подходить не всем. Например, она подходит одиноким людям, у которых времени вагон и они никуда не спешат. Им проще подождать пару часов и сэкономить пару 100$. Для семейных же, особенно с детьми, вы просто не будете успевать вовремя заряжать авто. Ну или будете успевать, тогда все остальные будут «ощущать» это на себе.
Это вы не уловили суть критики.
И да, понятно, что вы пытаетесь всячески оправдать (расход на заправку, посмотреть интересные места, возврат от государства и т.д.) покупку электро. Не все готовы признать ошибки/недостатки, некоторые начинают придумывать всё новые и новые оправдания, лишь бы не признавать, что у чего-то есть какие-то недостатки.
PS. Да и упоминание теслы тоже неуместно, хотя бы в том, что там запас хода в 2 раза больше. Если бы эта статья была про теслу, то я бы ещё понял всю прелесть от электро. А так, больше похоже на рекламу электро авто для езды за покупками, работа-дом.
Ещё раз повторю:
— вы написали статью, где условия доведены до идеальных.
— вы описали ситуацию, где обсуждаемый объект лишен недостатков
— вы написали статью на ресурсе, где 90% читателей живут в СНГ и им, возможно, и не понять, какова реальная ситуация у вас.
На что получили много минусов на комментарии и резкую критику.
PS. Если и после этого вы не поняли, что у вас в статье информация подана однобоко (причём вообще без изъянов/минусов), тогда у меня больше нет вопросов. Ну и логично, что критика читателей была соответствующая.
Про компьютер имеет смысл сравнивать, если он на батарее и его можно зарядить только в определённых местах (да и то, с условиями: нужно время, нужны свободные розетки и т.д.). В остальном, ваше сравнение лишено смысла.
Автор может сидеть за рулём чего-угодно, но писать, что это значительно круто, причём во всех ситуациях — это чей опыт «выше других»?
Может я не внимательно читал, но я так и не нашёл, где автор говорит о минусах электро. Да и про геопривязку я нигде не упоминал.
Да, именно так и должна была выглядеть статья: у меня есть 10 машин и одна из них электро. И это круто, когда ОДНА ИЗ авто — электро.
А статья выглядит так: у меня есть ТОЛЬКО ОДНА машина и она — электро, и это намного круче, чем авто с ДВС. И автору пытаются доказать, что он ошибается, указывают на явные недостатки, но он, как-будто, их не видит и живёт в своём, выдуманном мире, где всё классно.
PS. Почему-то вспомнился анекдот про работу пожарного: условия классные, спецодежда, бесплатное питание, соцзащита,… Но когда пожар — то хоть увольняйся.
Привязан к авто, это не «тупо сидеть в ней», а постоянно помнить про:
— у тебя всегда ДОЛЖНО быть СВОБОДНО 2-4 часа когда ты ставишь на полную зарядку. Быстрая зарядка — это круто, но, я так понимаю, она есть не везде.
— после того, как поставил за зарядку авто, ты должен через время вернуться и освободить место зарядки (или только розетку) для других таких же авто. Или вы вот просто уйдёте на целый день, тем самым заняв зарядный кабель?
— запас хода как минимум в 2 раза меньше, чем у машин с ДВС
Проще говоря, все ответы сводятся к следующим:
— я езжу только по определённым маршрутам, потому что знаю, что там есть зарядка и место где можно прогуляться (2-4 часа). по другим маршрутам не езжу, так как зачем?
— про работу понятно, что выбрали место работы, где есть зарядка.
— постоянно быть привязанным к авто, пока оно заряжается.
Что значит «доступная» зарядка? Это головная боль (каждый раз думай: хоть бы было свободно, хоть бы никто не занял, хоть бы я был первым и т.д.), даже в городе. Я уже спрашивал, что будет делать автор если…
А что будет делать автор, если приедет, а там уже стоит такой же, заряжается (хорошо, если его водитель рядом, а если оставил и ушёл?)? Будет ехать искать другую зарядку? Или ждать (а если ждать, то сколько?)? Или вынуть кабель и вставить в своё авто? Или ехать искать другую зарядку? Таких «или» очень много.
Если обычное авто с баком в 50 литров может проехать 500 км (в среднем), то кто должен чаще заезжать на АЗС? А что вы делаете, если вам нужно поехать на отдых на другой конец страны, например, проехать 500 км? Сколько суток будет занимать обычная поездка? А что, если вам нужно будет заехать в какую-то глушь, где рядом нет зарядок? Обычные автолюбители могут взять с собой канистру или две.
200 км очень мало, а летом/зимой, когда нужна печка/климат, то выходит 180, а учитывая, что вы не разряжаете батарею до полной, то выходит где-то каждые 150 км нужно заряжать. Возникает вопрос: для чего ЕЩЁ нужно такое авто, кроме как поездка из/в дома/работу? И конечно, если вы поменяете работу, то на новом месте ДОЛЖНА быть зарядка для авто, иначе, будете оставлять авто на ближайшей заправке, тем самым занимая розетку на целый день. Или будете каждый час/два ходить и проверять, зарядилась ли батарея.
PS. В половине фото из статьи только 1 розетка. Представляю, если одновременно приедет 2 таких авто, то как минимум час на заправке вам обеспечен.
Кто-то может назвать установку агентов недостатком, но для меня - преимущество. Особенно тогда, когда невозможно (причин может быть много, от ошибка конфигурации в ssh до банального зависания) подключиться по ssh. Очень много раз спасало именно наличие minion: просто отдаешь ему команду на выполнение. Да, не всегда с первого раза, но в данном случае уже есть установленное соединение по которому можно отправить команду. Не нужно делать новое сетевое подключение, не нужно ждать согласование cipher'ов и прочего.
Опять же. Если у вам "дешевле" отправить сервер в reboot, то salt проигрывает ansibl'y, но если сервер крайне не желательно перезагружать, и иметь дополнительную возможность подключения - преимущество у salt'a.
На самом деле это не совсем так. ключ "-L" покажет список всех ключей, которые разбиты на несколько категорий: одобреные (Accepted), ожидающие (Unaccepted), заблокированные (там 2 вида: Rejected/Denied). Так вот, только ожидающие будут соответствовать "которые пытаются подключиться к Master".
Теперь про сам ключ "-A". Я бы не рекомендовал его использовать, так как он автоматически принимает все ключи. Лучше для этого использовать конструкцию " salt-key -a '*' " и salt покажет какие ключи будут добавлены и спросит "добавить?". Иногда бывает, что кто-то хочет добавить какой-то тестовый однодневный docker-контейнер. Не нужно забывать еще о некоторой особенности salt-stack: не активные ключи нужно время от времени удалять, так как они влияют на выполнение batch'евый заданий (когда применяется к группе). К примеру, у вас задание salt -G roles:DNS state.sls dns_prod и, если у вас хотя бы один мертвый ключ с ролью DNS, вы будете ожидать возврата терминала 60 секунд (by default), не смотря на то, что все minion'ы уже вернули статус выполнения stat'a. Поэтому, я за то, что бы не слепо "принимать" все ключи, а еще раз перепроверять, что принимать. Хотя, кому как удобнее.
Более того, с появлением GTID-репликации, проблем стало гораздо меньше (да, она чуть сложнее, да, есть нюансы, но всё это нивелируется с её преимуществами по сравнению с обычной).
Есть вопрос, в первую очередь, автору (а так же всем остальным, кто его использовал) касательно SO_REUSEPORT. AFAIK, у вас linux. Так вот, как вы увидели, что REUSEPORT у вас действительно используется (снижение нагрузки не в счёт, так как на это может влиять что угодно)? Каким механизмом? Например, во FreeBSD это можно посмотреть через procstat, а в linux'e как (перелопатил много чего, но кроме того, как это пихать в код не нашёл; ещё нашёл как-то патч от 2013 года для netstat'a, но это как-то костыльно)?
— owncloud очень жутко тормозит, и упора в железо или кеширования нет. как это победить — неясно. Пробовал и памяти доставлять и opcache/memcache тюнить по параметрам, толку 0. гугление вообще не даёт толковых советов, кроме как «включите opcache/memcache»
— onlyoffice тоже не работает нормально. По крайней мере при попытке открыть через него doc/xls ругается. гугление, так же не помогает.
ну, то есть, продукт nextcloud из разряда монстров, которые написаны абы как.
PS. сейчас пути файлов немного изменились, но суть и порядок обработки остался прежним.
То, что вы назвали, это реально и полезно, кому-то другому, но не DBA. Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать. Экономию денег посчитаете во время сбоя DB и сроков её восстановления.
Если мне нужно будет писать много-много данных с большой-большой скоростью, то это точно не должна быть mysql, ибо она для этого не годится. Тут или NoSQL выбирать или искать другие решения. И да, я выбираю по принципу: для каждой задачи должна быть DB максимально ей отвечающая. То есть я НЕ буду пихать везде MY, потому что она мне больше симпатизирует. Если объективно она туда не подходит — то зачем её там использовать? Доказать, что что-то может работать на MY? Смысл?
Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов. Нигде нет супер-пупер скорости отдачи страниц, особенно, когда идут какие-то оплаты. Вы можете ждать и 5 и 10 секунд, и это нормально. Нет, я не говорю о каких-то минутах. Им надёжнее отдать вам страницу позже, чем потом разбираться с тем, у кого сколько денег пропало. Это если вы говорите об экономии больших денег. Я на 99% уверен, что у них oracle, но даже в этом ключе они не стремятся к быстродействию ради милисекунд.
PS. Я прекращаю дальнейшую дискуссию.
2. Да, можно многими способами, но процент успешной миграции в моём случае был очень невелик. Зачем мне переписывать код, если дело в конкретном exten'e? Это глупо и неправильно. Правильно было бы во время дампа указать его, что есть такой exten и лежит там-то. Но нет, как ни подсовывал ему, ему всё не нравилось. Это первый пример. Второй пример, это функция digest из стандартного exten'a pgcrypto (он правда не подключён по умолчанию, но ведь это не должно быть проблемой при дампе). Итого, исходя из ваших слов, или не пользоваться вообще exten'aми, ибо всё, что не включено по дефолту сломается при обновлении, либо каждый раз переписывать код. Зачем тогда вообще нужны такие exten'ы, которые создают больше проблем чем профита?
3.
4. Пускай хоть 15-ая. Скажите, что из этих 4-ох пунктов имеет Postgres на текущий момент, не смотря на то, что у mysql это уже как несколько лет есть? Или назовите, чем он лучше для DBA в плане обслуживания и что имеет такого, чего нет в mysql и оно реально крутое? Я сейчас не про 100500 разных индексов, а про то, что реально может быть полезно.
Вы опять всё клоните в сторону разработчика, а не DBA. DBA в первую очередь волнует как это можно масштабировать, обновить, бэкапить и потом восстановить. То, что запросы будут выполняться быстрее или медленнее, это уже второй вопрос. Да, анализатор запросов в PQ лучше, чем в mysql, тут не спорю, но ради этого менять БД — сомнительно.
Mysql может нормально работать на HighLoad, главное правильно «приготовить». Зачем mysql? Затем, что его проще и надёжнее обслуживать.
Тут хочется вспомнить анекдот про работу пожарным: «На работе хорошо и бесплатно кормят, есть бесплатная спецодежда, можно поспать в рабочее время, хороший коллектив, но когда пожар — хоть увольняйся».
Кстати, пока писал коммент, вспомнил, что для mysql есть percona toolkit, который имеет ну очень полезную фичу, которая пару раз очень выручала: сделать консистентной реплику. То есть, предположим, что в одной из реплик часть данных пропали (как, это неважно: либо кто-то случайно удалил, либо по ошибкам не дошли, либо реплика долго была отключена, либо...). Как досинкать только недостающие данные, например, на 100Гб таблице, при этом, учитывая то, что в этот момент идёт репликация? Если для postgres'a есть такое же, я за него буду только рад.
Ещё раз повторюсь для всех, меня интересует сравнение PQ и MY ТОЛЬКО в плане DBA.
Если случился обычный crash, то данные восстанавливаются в 99% автоматически. Если так случилось, что не удалось, а это бывает крайне редко, то есть метод опция innodb_force_recovery=6, в которой база поднимается в режиме RO, неважно, насколько убита InnoDB. Можно сделать дамп, даже пропустив сбойные (если например, на диски появились bad block'и) строки, это проверенный факт.
PS. Да, в версии 5.1 (но это было ого-го когда, тогда и PQ наверное от простого ребута мог завалиться) это было часто, но тогда движок InnoDB только был в зародыше. Начиная с 5.5, это успех восстановления был уже на уровне 90%, а в 5.6 он достиг уже 99%.
1) Репликация.
Чего стоит мучительная репликация, которая в mysql появилась, лет, наверное 10 назад, причём не тупо «всё реплицировать», а выбирать, какие базы, таблицы. Да, в postgres'e были всякие костыли типа slony, и даже в 9-ке появилась родная binary-репликация (и да, всё так же «все реплицировать») в одну сторону (на тот момент в mysql уже давно была master-master). Вроде бы в 10-ке появилась logical, где уже можно выбирать, что реплицировать. Да, это прорыв, но почему так поздно? С тех пор я перестал следить за PQ. Я не знаю, может в 12 появилась уже master-master репликация, тогда шансы уровнялись в этой части. А может PQ умеет реплицироваться сразу с нескольких источников? mysql такое умеет, как минимум года 3.
2) upgrade с версии на версию.
Это страшный сон всех PQ DBA, даже если версии минорные, особенно, если у тебя есть custom'ные exten'ы. Ну вот нельзя просто поставить новую версию, запустить скрипт upgrad'a и всё. И это mysql умеет очень давно. Но PQ до 9.Х включительно не имел такого инструмента. Как дела в PQ в 12-ой версии — я не знаю, возможно, спустя много лет, что-то появилось.
3) recovery table
Если таблица очень большая и дамп по каким-то причинам долго переносить/делать, то можно с рабочего сервера сделать копию файла ibd (если InnoDB) потом через DISCARD/IMPORT можно «подключить» таблицу в работающую базу. Тут успех, где-то 70%, но всё-равно не малый.
4) 32-ух битный номер транзакций. Это боль для высоконагруженных БД. Такое случается очень редко, но когда случилось — это катастрофа. Как чинить — непонятно (была статья на хабре, где писали за деньги патч под это дело). Вроде бы в 10 или 11 он уже 64-их битный, но что делать было раньше? Надеятся, что ты никогда с таким не столкнёшься?
Это самые большие проблемы, с которыми приходилось мириться (и надеятся, что они никогда не настанут) и мы перешли на mysql. Были ещё мелкие недочёты, но они несущественны.
Вы могли бы мне назвать причины, в чём PQ лучше MY, как для DBA?
Если я не так сравниваю, укажите, где именно я ошибся. Расскажите, как правильно сравнивать.
Мне кажется, что экономическая выгода будет подходить не всем. Например, она подходит одиноким людям, у которых времени вагон и они никуда не спешат. Им проще подождать пару часов и сэкономить пару 100$. Для семейных же, особенно с детьми, вы просто не будете успевать вовремя заряжать авто. Ну или будете успевать, тогда все остальные будут «ощущать» это на себе.
И да, понятно, что вы пытаетесь всячески оправдать (расход на заправку, посмотреть интересные места, возврат от государства и т.д.) покупку электро. Не все готовы признать ошибки/недостатки, некоторые начинают придумывать всё новые и новые оправдания, лишь бы не признавать, что у чего-то есть какие-то недостатки.
PS. Да и упоминание теслы тоже неуместно, хотя бы в том, что там запас хода в 2 раза больше. Если бы эта статья была про теслу, то я бы ещё понял всю прелесть от электро. А так, больше похоже на рекламу электро авто для езды за покупками, работа-дом.
— вы написали статью, где условия доведены до идеальных.
— вы описали ситуацию, где обсуждаемый объект лишен недостатков
— вы написали статью на ресурсе, где 90% читателей живут в СНГ и им, возможно, и не понять, какова реальная ситуация у вас.
На что получили много минусов на комментарии и резкую критику.
PS. Если и после этого вы не поняли, что у вас в статье информация подана однобоко (причём вообще без изъянов/минусов), тогда у меня больше нет вопросов. Ну и логично, что критика читателей была соответствующая.
Или я не понял, к чему это видео.
Автор может сидеть за рулём чего-угодно, но писать, что это значительно круто, причём во всех ситуациях — это чей опыт «выше других»?
Может я не внимательно читал, но я так и не нашёл, где автор говорит о минусах электро. Да и про геопривязку я нигде не упоминал.
А статья выглядит так: у меня есть ТОЛЬКО ОДНА машина и она — электро, и это намного круче, чем авто с ДВС. И автору пытаются доказать, что он ошибается, указывают на явные недостатки, но он, как-будто, их не видит и живёт в своём, выдуманном мире, где всё классно.
PS. Почему-то вспомнился анекдот про работу пожарного: условия классные, спецодежда, бесплатное питание, соцзащита,… Но когда пожар — то хоть увольняйся.
— у тебя всегда ДОЛЖНО быть СВОБОДНО 2-4 часа когда ты ставишь на полную зарядку. Быстрая зарядка — это круто, но, я так понимаю, она есть не везде.
— после того, как поставил за зарядку авто, ты должен через время вернуться и освободить место зарядки (или только розетку) для других таких же авто. Или вы вот просто уйдёте на целый день, тем самым заняв зарядный кабель?
— запас хода как минимум в 2 раза меньше, чем у машин с ДВС
— я езжу только по определённым маршрутам, потому что знаю, что там есть зарядка и место где можно прогуляться (2-4 часа). по другим маршрутам не езжу, так как зачем?
— про работу понятно, что выбрали место работы, где есть зарядка.
— постоянно быть привязанным к авто, пока оно заряжается.
Если обычное авто с баком в 50 литров может проехать 500 км (в среднем), то кто должен чаще заезжать на АЗС? А что вы делаете, если вам нужно поехать на отдых на другой конец страны, например, проехать 500 км? Сколько суток будет занимать обычная поездка? А что, если вам нужно будет заехать в какую-то глушь, где рядом нет зарядок? Обычные автолюбители могут взять с собой канистру или две.
200 км очень мало, а летом/зимой, когда нужна печка/климат, то выходит 180, а учитывая, что вы не разряжаете батарею до полной, то выходит где-то каждые 150 км нужно заряжать. Возникает вопрос: для чего ЕЩЁ нужно такое авто, кроме как поездка из/в дома/работу? И конечно, если вы поменяете работу, то на новом месте ДОЛЖНА быть зарядка для авто, иначе, будете оставлять авто на ближайшей заправке, тем самым занимая розетку на целый день. Или будете каждый час/два ходить и проверять, зарядилась ли батарея.
PS. В половине фото из статьи только 1 розетка. Представляю, если одновременно приедет 2 таких авто, то как минимум час на заправке вам обеспечен.