Pull to refresh
-2
Karma
0
Rating
Сергей @skeletor

Пользователь

FreeBSD. Путь сетевого пакета внутри ядра

Не вариант. К примеру, на работающем ipfw вы подгрузили pf или ipfilter, то rcorder покажет неверную информацию. Если кратко, то так — www.opennet.ru/tips/1431_ipfw_firwall_pf_freebsd.shtml

PS. сейчас пути файлов немного изменились, но суть и порядок обработки остался прежним.

Оптимизация mysql комплексная

В общем, я вижу, что вы уходите от прямых ответов, поэтому спорить тут бессмысленно. У вас всё сводится к тому, что «не было, не должно быть и это должно мониториться и т.д.». Вы должны быть готовы к любым ситуациям, и, если конкретная БД этого не умеет или это будет очень и очень сложно — то зачем её использовать под эти задачи изначально?

То, что вы назвали, это реально и полезно, кому-то другому, но не DBA. Не нужно говорить, что сайт на mysql будет тормозить, а на postgres будет летать. Экономию денег посчитаете во время сбоя DB и сроков её восстановления.

Если мне нужно будет писать много-много данных с большой-большой скоростью, то это точно не должна быть mysql, ибо она для этого не годится. Тут или NoSQL выбирать или искать другие решения. И да, я выбираю по принципу: для каждой задачи должна быть DB максимально ей отвечающая. То есть я НЕ буду пихать везде MY, потому что она мне больше симпатизирует. Если объективно она туда не подходит — то зачем её там использовать? Доказать, что что-то может работать на MY? Смысл?

Насчёт скорости: посмотрите на работу банков, особенно их личных кабинетов. Нигде нет супер-пупер скорости отдачи страниц, особенно, когда идут какие-то оплаты. Вы можете ждать и 5 и 10 секунд, и это нормально. Нет, я не говорю о каких-то минутах. Им надёжнее отдать вам страницу позже, чем потом разбираться с тем, у кого сколько денег пропало. Это если вы говорите об экономии больших денег. Я на 99% уверен, что у них oracle, но даже в этом ключе они не стремятся к быстродействию ради милисекунд.

PS. Я прекращаю дальнейшую дискуссию.

Оптимизация mysql комплексная

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.

Оптимизация mysql комплексная

Неправда.
Если случился обычный crash, то данные восстанавливаются в 99% автоматически. Если так случилось, что не удалось, а это бывает крайне редко, то есть метод опция innodb_force_recovery=6, в которой база поднимается в режиме RO, неважно, насколько убита InnoDB. Можно сделать дамп, даже пропустив сбойные (если например, на диски появились bad block'и) строки, это проверенный факт.

PS. Да, в версии 5.1 (но это было ого-го когда, тогда и PQ наверное от простого ребута мог завалиться) это было часто, но тогда движок InnoDB только был в зародыше. Начиная с 5.5, это успех восстановления был уже на уровне 90%, а в 5.6 он достиг уже 99%.

Оптимизация mysql комплексная

Когда говорят, что 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 таких авто, то как минимум час на заправке вам обеспечен.

Samba в роли ADDC в Solaris 11.4

А какие-то ошибки выдавал? Может их можно решить без кастомного python'a?
Вообще, кастомный python в Solaris лучше не ставить, и больше того, не ставить даже через pip ничего — только через pkg install (если нет готового пакета — собрать самому и поставить). Иначе, после обновления будет много проблем, так как на python завязано почти половина системы, включая и сам пакетный менеджер.

Samba в роли ADDC в Solaris 11.4

Конфиг smb.conf никак не влияет на тип ФС (если не учитывать момент с ACL), поэтому можете брать любой.
Вопрос про configure не понял. У вас в статье он дефолтный и с ним всё работает.

Samba в роли ADDC в Solaris 11.4

Когда я спрашивал, подразумевал, что именно не сложилось с ZFS ACL, почему именно нужно POSIX ACL? Хочется больше подробностей. И Кстати, в samba ZFS (NFS) ACL нормально так интегрируются www.samba.org/samba/docs/current/man-html/vfs_zfsacl.8.html. Тоже самое и про python (с какими трудностями столкнулся автор?).

Samba в роли ADDC в Solaris 11.4

1) Зачем собирать python-27, если он уже есть в пакетах? Я понимаю, если нужно как-то кастомно, но в статье дефолтные настройки сборки
2) Зачем использовать UFS? Какая выгода по сравнению с ZFS?

Information

Rating
5,863-rd
Location
Украина
Registered
Activity