всем привет. можете подсказать по марии с импортом дампа? у меня дамп. размер примерно гигов 40-50 (в сжатом виде - 10). сделан с мускуля. я его пробую импортировать на центосе в марию из реп. 1. импорт идет очень долго. 2. спустя ~7 часов импорта он прервался с сообщением "ERROR 2013 (HY000) at line 38937: Lost connection to MySQL server during query"

Ну а что ты хочешь, объем немалый, а почему падает - гляди в логах

Ну а что ты хочешь, объем немалый, а почему падает - гляди в логах

почему упало я нашел. место кончилось =)

как-то проморгал момент этот совсем. хорошо это тестовая машина

там не просто обновление с мускуля на марию. там перенос на другую машину

Сделай реплику само перетянет

я щас погонял тесты fio. и у меня пока складывается ощущение, что я при импорте дампа упираюсь все-таки в иопсы дисковой.

Сделай реплику само перетянет

между мускулем и марией?

Раз тестовая - попробуй xtrabackup натравить

Раз тестовая - попробуй xtrabackup натравить

посмотрю что такое. спасибо

Сделай реплику само перетянет

вообще была идея такая, но сначала решил через дамп. а там и приключения начались... =) тоже гляну как можно реплику сделать. спасибо

насчет fio. я правильно понимаю, что импорт дампа - это random write и в один поток?

вообще была идея такая, но сначала решил через дамп. а там и приключения начались... =) тоже гляну как можно реплику сделать. спасибо

Ну можно тупо скопировать фолдеры целиком на новую машину и там проапгрейдить

Ну можно тупо скопировать фолдеры целиком на новую машину и там проапгрейдить

опа, этот вариант я что-то совсем не рассматривал

тоже проверю, спасибо

между мускулем и марией?

https://mariadb.com/kb/en/library/setting-up-replication/#replicating-from-mysql-master-to-mariadb-slave

Добрый день! Ребят я правильно понимаю, что один из индексов можно удалить?

Только не Primary)

)

второй то есть можно ?

второй то есть можно ?

Ешь на здоровье!

спасибо)

Добрый день! Ребят я правильно понимаю, что один из индексов можно удалить?

Да правильно

?

ALTER TABLE "schedule_days" ALTER COLUMN "period" TYPE INTEGER (10);

у меня таблице тип периода стоит DATE

его хочу менят на INTEGER

но дает ошибка

читай внимательно документацию на команду

изменяешь колонку, но для чего и как - непонятно

как ест тут так и написал я! это postgresql

читай внимательно документацию на команду

так у него команда правильная, у него тип кривой

как ест тут так и написал я! это postgresql

https://www.postgresql.org/docs/9.2/static/datatype-numeric.html#DATATYPE-INT почитай чтольи какие типы есть

так у него команда правильная, у него тип кривой

как писат правилно?

правильно - писать существующий тип. Например почитать в документации, что есть прежде чем что-то ставить

можеш писат как будет правилно?

так у него команда правильная, у него тип кривой

ну я думал очередной мускул вылез, поэтому посмотрел мускул ?

у меня period шас DATE

ну я думал очередной мускул вылез, поэтому посмотрел мускул ?

ну там видно на скрине пг_тост_темп слева)

можеш писат как будет правилно?

в документации описаны все правильные типы

https://www.postgresql.org/docs/9.2/static/datatype.html вон смотри сколько их

ну там видно на скрине пг_тост_темп слева)

ну начинается, там и паблик видно, но мне лень, ибо автору лень было написать базу

а че, в мускуле типа по-другому альтер колонок лол?

modfily надо вроде

а че, в мускуле типа по-другому альтер колонок лол?

да, хочешь поменять тип, пиши CHANGE

а, ну это еще безобидно)

Добрый день. Ребят, подскажите пожалуйста, а можно как-то связывать схемы в одной БД? Допустим я хочу сделать отдельные схемы на все модули приложения, например все что связано с пользователями и отношениями организаций в одну схему, все что связано со складом в другую, все что с проектированием изделий в третью, и т.д. Но дело в том, что важна тесная связь и перекрестная ссылочность таблиц из разных схем в таком случае. Для чего так извращаться? Проектируемая система будет больших размеров с богатым функционалом, если все пихать в одну схему, то Хорус поднимет голову. Хотелось бы чтоб все по полочкам. Такое вообще возможно? Или не валять дурака и все пхать в одну схему?

привет. В Mysql например никаких ограничений на связи между схемами нет

Добрый день. Ребят, подскажите пожалуйста, а можно как-то связывать схемы в одной БД? Допустим я хочу сделать отдельные схемы на все модули приложения, например все что связано с пользователями и отношениями организаций в одну схему, все что связано со складом в другую, все что с проектированием изделий в третью, и т.д. Но дело в том, что важна тесная связь и перекрестная ссылочность таблиц из разных схем в таком случае. Для чего так извращаться? Проектируемая система будет больших размеров с богатым функционалом, если все пихать в одну схему, то Хорус поднимет голову. Хотелось бы чтоб все по полочкам. Такое вообще возможно? Или не валять дурака и все пхать в одну схему?

Зря так хочешь. Не стоит.

Говна хлебнешь

Добрый день. Ребят, подскажите пожалуйста, а можно как-то связывать схемы в одной БД? Допустим я хочу сделать отдельные схемы на все модули приложения, например все что связано с пользователями и отношениями организаций в одну схему, все что связано со складом в другую, все что с проектированием изделий в третью, и т.д. Но дело в том, что важна тесная связь и перекрестная ссылочность таблиц из разных схем в таком случае. Для чего так извращаться? Проектируемая система будет больших размеров с богатым функционалом, если все пихать в одну схему, то Хорус поднимет голову. Хотелось бы чтоб все по полочкам. Такое вообще возможно? Или не валять дурака и все пхать в одну схему?

Дело в том, что понятия схем и баз данных в разных СУБД разные. Разделяя это по схемам ты заранее обрекаешь себя на привязанность к данной субд. Глобально концепция должна быть такой: одно приложение (одна система) - одна схема/база данных. Поскольку ту ничего не выиграешь от такого разделения, а проиграешь много чего в сложности организации базы данных, то получается что так просто нет никакого смысла делать.

Говна хлебнешь

Во, у меня так кратко не получается.

Дело в том, что понятия схем и баз данных в разных СУБД разные. Разделяя это по схемам ты заранее обрекаешь себя на привязанность к данной субд. Глобально концепция должна быть такой: одно приложение (одна система) - одна схема/база данных. Поскольку ту ничего не выиграешь от такого разделения, а проиграешь много чего в сложности организации базы данных, то получается что так просто нет никакого смысла делать.

Понял, спасибо. =)

Понял, спасибо. =)

Ты же типа только хотел, чтобы "всё аккуратно было и таблиц было меньше чтобы искать легче" ?

Добрый день. Ребят, подскажите пожалуйста, а можно как-то связывать схемы в одной БД? Допустим я хочу сделать отдельные схемы на все модули приложения, например все что связано с пользователями и отношениями организаций в одну схему, все что связано со складом в другую, все что с проектированием изделий в третью, и т.д. Но дело в том, что важна тесная связь и перекрестная ссылочность таблиц из разных схем в таком случае. Для чего так извращаться? Проектируемая система будет больших размеров с богатым функционалом, если все пихать в одну схему, то Хорус поднимет голову. Хотелось бы чтоб все по полочкам. Такое вообще возможно? Или не валять дурака и все пхать в одну схему?

Какое-то промежуточное состояние. Если надо хранилище, то надо собирать все, если надо разделить апликейшены, то лучше вообще отдельные инстансы с базами поднимать для каждого

микросервисная архитектура, вся фигня

Ты же типа только хотел, чтобы "всё аккуратно было и таблиц было меньше чтобы искать легче" ?

да, плюс EER диаграммы отдельно разрабатывать, а не допиливать одну большую паутину

да, плюс EER диаграммы отдельно разрабатывать, а не допиливать одну большую паутину

А если не будет одной больлшой паутины, не будет и связей.

Лучше рисуй одну большую паутину.

Это намного универсальнее.

Да, так и буду делать.

ERROR: S client not available

надо будет разобраться, как в процедуры передавать переменные, например, по какому полю фильтровать.

Параметры есть у процедур.

А если не будет одной больлшой паутины, не будет и связей.

Связи будут всегда. Через приложение. Просто если вся его система изначально делится на отдельные куски то имеет смысл это реализовывать как написал @SLASH_CyberPunk

Ребята, добрый день! Столкнулись с тем, что на ЯП не контролировалась длина строк при вставке в varchar(N), ранее программы работали с СУБД Maria, на которой не было строгого режима, полагались на то, что она сама обрежет строки до нужной длины. Переключили на СУБД с включенным строгим режимом - пошли ошибки. Есть ли рекомендации по использованию режима strict_trans_tables? Интересует - должен ли он быть по умолчанию включен всегда/на_продах? Или допустимо в качестве альтернативы ловить warnings в ЯП?

А валить все в одну большую кучу это такое... запаришся потом железом заваливать если оно вдруг полетит

Связи будут всегда. Через приложение. Просто если вся его система изначально делится на отдельные куски то имеет смысл это реализовывать как написал @SLASH_CyberPunk

Согласен микросервисы в таком случае лучше , быстрее вносить правки

Согласен микросервисы в таком случае лучше , быстрее вносить правки

Правки одни. Можно более гибко нагрузку распределять.

В общем сплошные плюсы

Согласен микросервисы в таком случае лучше , быстрее вносить правки

Тут скорее в первую очередь гибкость выбора для команды разработки

Ибо команды разные бывают

Тут скорее в первую очередь гибкость выбора для команды разработки

И это тоже. Можно порвать на куски и реализовать кому на чем нравиться:)

Ну и под задачу

Так что мысль вернаЯ. Только реализация недодуманная

А сторонников валить все в кучу - в лес с лобзиками.

все в кучу - это хранилище, там другие правила

Ребята, добрый день! Столкнулись с тем, что на ЯП не контролировалась длина строк при вставке в varchar(N), ранее программы работали с СУБД Maria, на которой не было строгого режима, полагались на то, что она сама обрежет строки до нужной длины. Переключили на СУБД с включенным строгим режимом - пошли ошибки. Есть ли рекомендации по использованию режима strict_trans_tables? Интересует - должен ли он быть по умолчанию включен всегда/на_продах? Или допустимо в качестве альтернативы ловить warnings в ЯП?

Кто-нибудь подскажет лучшие практики?

Кто-нибудь подскажет лучшие практики?

а в чем сокральный смысл класть данные таким образом, чтобы проебать их возможно важную часть?

а в чем сокральный смысл класть данные таким образом, чтобы проебать их возможно важную часть?

В данном конкретном случае эта часть не важна. Согласен, есть кейсы, когда важна полнота данных, для них используется тип TEXT для полей. Здесь же более важны другие поля записи, это же поле больше для информации, которая потом может быть представлена в отчёте.

а в чем сокральный смысл класть данные таким образом, чтобы проебать их возможно важную часть?

Ты в чатиге оракла не видел. Там чувак 20 терабайт базу на синлг машине снапшоты делает?

Возможно, это и к лучшему

В данном конкретном случае эта часть не важна. Согласен, есть кейсы, когда важна полнота данных, для них используется тип TEXT для полей. Здесь же более важны другие поля записи, это же поле больше для информации, которая потом может быть представлена в отчёте.

А может не быть? Я пытаюсь представить отчет в котором огрызки фраз например. Вместо строчек только точки.. догадайся мол сама..

Зачем тогда было дизайнить схему где varchar(n)...

Если это не важно то нафиг вообще эту колонку?

Непанятна

Да и собственно средства яп не позволяют преобразовать/обрезать/закодировать?

Ок, я вас понял, то есть строгий режим обязателен, верно?

Пиши в варчар кодовые буквы которые яп будет расшифровывать в месаджи

Пиши в варчар кодовые буквы которые яп будет расшифровывать в месаджи

Вот это не совсем понял.

это он про шаблоны так затейливо сказал

это он про шаблоны так затейливо сказал

Ну хэши тоже проканают

Ок. То есть лучшей практикой является использование строгого режима, что означает перенос ответственности за подготовку данных на ЯП, а БД - только для хранения.