1.3, Аноним (3), 22:09, 24/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –18 +/– |
Как они задолбали своей марией. После установки мускуля незя нормально к нему подключиться без шаманства как раз таки из-за этих марий по умолчанию
| |
|
|
3.31, Ilya Indigo (ok), 10:37, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Из-за чего это? Порт по-умолчанию другой?
Мне аж стало интересно. Если в системе 2 инстанса, ну или мария с мускулулом и у обоих skip-networking то есть только по сокетам. А из клиента я подключаюсь как localhost. Сервер по портам определять имя сокета будет? По другому это работать же просто не может, но видимо именно так он и делает.
| |
|
4.34, turbo2001 (ok), 12:02, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Сервер по портам определять имя сокета будет?
Не понял вопрос, но у меня есть теория. В дистре анонима при установке двух серверов настройки порта/сокета выносятся в секции конфига типа [mysqld.blabla1] и [mysqld.blabla2]. Из-за чего секция [mysqld] оказывается пустая и клиенту в любом случае надо указывать название секции или сокета, что и не нравится анониму. Но правды, похоже, я так и не узнаю.
| |
|
5.35, Ilya Indigo (ok), 12:40, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Сервер по портам определять имя сокета будет?
> Не понял вопрос, но у меня есть теория. В дистре анонима при
> установке двух серверов настройки порта/сокета выносятся в секции конфига типа [mysqld.blabla1]
> и [mysqld.blabla2]. Из-за чего секция [mysqld] оказывается пустая и клиенту в
> любом случае надо указывать название секции или сокета, что и не
> нравится анониму. Но правды, похоже, я так и не узнаю.
Скорее всего так.
Просто в mysql единственное клиент-серверное ПО, которое я знаю, в котором весьма странно решили реализовать подключение через сокет, по ключевому слову localhost, возможно для совместимости с оффтопиком, где сокетов нет вообще. И не все знают что localhost и 127.0.0.1 это в mysql не одно и тоже, по крайней мере в линуксе. И возможно, все проблемы из-за этого.
Я никогда не использовал более 1-ого инстанса и всегда использовал skip-networking и localhost не задумываясь как сервер определяет имя сокета если я его не указываю, так как он у меня всегда был 1.
А сейчас я просто представил, что будет если у меня будут 2 инстанса и все со skip-networking с разными сокетами, а порты разные не все догадаются поставить разные, ведь я хочу по сокету работать и можно подумать порт мне вообще не нужен.
А mysql, видимо работая через сокет именно по порту определяет к какому сокету ей подключаться. То есть порт нужен даже если не используется сеть.
А можно же было просто в подключении по сокету вместо хоста и порта указать имя сокета, или если порт 0, то перед ним идёт имя сокета а не имя хоста (как в redis) и проблем с пониманием было бы меньше.
| |
|
6.38, turbo2001 (ok), 13:38, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А mysql, видимо работая через сокет именно по порту определяет к какому сокету ей подключаться. То есть порт нужен даже если не используется сеть.
Да нету такого. mysql (клиент, который) берет название сокета из конфига (секция в --defaults-group-suffix указывается) или напрямую (--socket).
| |
|
|
4.42, Аноним (42), 18:46, 27/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
mysql -S /path/to/socket
> А из клиента я подключаюсь как localhost
нет, из клиента ты при skip-networking подключаешься к дефолтному юникс-сокету. Дефолтный - тот, который задан при компиляции.
Это такой костыль в libmysql для макак, программирующих на пхп со словарем - если задан localhost, то сначала пробуем сконнектиться на дефолтный сокет.
| |
|
|
|
1.4, Gemorroj (ok), 22:19, 24/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> сохраняющее обратную совместимость
нихрена не сохраняющее. тот же json сделали абы как (это алиас к varchar, а не отдельная структура как в ваниле)
| |
|
2.25, ann (??), 22:54, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
json сам по себе обы что и абы как, его нельзя нормально сделать.
| |
2.36, userd (ok), 12:43, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Можно повспоминать, что в момент форка непосредственной поддержки json ещё не было.
Так что да, "сохраняющее", но не обязательно "поддерживающее".
| |
|
3.37, Gemorroj (ok), 12:47, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Можно повспоминать, что в момент форка непосредственной поддержки json ещё не было.
> Так что да, "сохраняющее", но не обязательно "поддерживающее".
да, вот эти человеки пошли своим путем, запилили первыми свой недо-json и теперь хрен знает как они это фиксить будут. заявили бы, что поддерживают совместимость на уровне mysql 5.5, например, тогда бы вопросов меньше было.
а то сейчас развелось много дилетантов, которые думают "maria - это тот же mysql, только круче/моднее/хайповее". приходится с этим вступать в конфронтацию.
| |
|
|
|
2.16, Аноним (16), 10:26, 25/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
В Nginx так и ге завезли, хотя это все припарки. Intel Hyperscan simd regexp их всех уделывает в десятки гбит
| |
|
3.22, Андрей (??), 20:27, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Не слышал, хотя в Debian уже почти 4 года как есть. Наверняка, так быстро только с использованием всяких AVX, а в дистрибутивах собирают для generic amd64, чтобы у всех работало и выиграша нет. Да и, может, оно сильно не совместимо по API / синтаксису.
Смотрю в Debian при сборке nginx TLS 1.3 чуть больше недели назад включили. Да и Lua всего 5.1.
| |
|
|
1.6, Аноним (6), 22:57, 24/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +11 +/– |
> Конструкция DROP TABLE теперь надёжно удаляет таблицы
Лучшее изменение ever!
| |
1.8, Аноним (8), 00:29, 25/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Добавлен движок хранения ColumnStore, который хранит данные в привязке к столбцам
Так я не понял это что clickhouse в опасности?
| |
|
2.9, Нитрофос (?), 01:27, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Есть немного, надо затестить.
Когда-то колумнстор был тормознее, но тут хорошие плюшки из-за соседства с обычными таблицами.
В сиквеле это соседство оч хорошо заходит.
| |
2.15, Аноним (16), 10:24, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
По функционалу нет и по производительности даже не близко. Ядро mysql имеет кучу болячек.
| |
|
1.10, Аноним (11), 04:26, 25/06/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
INET6 это ужасный костыль, в PostgreSQL идеальное решение с универсальными типами.
| |
|
2.12, Аноним (11), 07:22, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
В Clickhouse подход как и в MariaDB... INET6 и INET4 отдельно типы данных....
| |
2.20, Аноним (19), 15:26, 25/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я в MySQL/MariaDB использовал BLOB с преобразованием INET6_ATON, INET6_NTOA. Тогда тоже можно и IPv4 и IPv6 хранить в таком поле.
| |
|
3.21, Ilya Indigo (ok), 15:53, 25/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
А правильно его хранить в VARBINARY(16) NOT NULL в двоичных данных!
P.S. VARBINARY, а не BINARY потомучто там может быть и IPv4.
| |
|
|
5.32, Аноним (19), 10:46, 26/06/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Очень удобно работать с бинарным блобом...
Ну хоть как-то работать. Но если реально нужно такие данные массово хранить, то стоит задуматься о лучшем хранилище, PostgreSQL, например.
| |
5.33, Ilya Indigo (ok), 11:41, 26/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Очень удобно работать с бинарным блобом...
Да! И места занимает минимум, и интерпретируется однозначно (один и тот же IPv6 можно по-разному представить в цифровой форме, а в бинарке он всегда один и тот же), и благодаря INET6_ATON() и INET6_NTOA() его очень удобно переводить из одной формы в другую при записи и чтении.
| |
5.43, Аноним (43), 11:59, 29/06/2020 [^] [^^] [^^^] [ответить]
| +/– |
Когда ж вы отучитесь говорить "CD-диск".
Blob - binary large object. И binary blob получается... Binary binary large object. Маслим масло масленным маслом.
| |
|
|
|
|
|