я то думал сам xtrabackup это умеет делать

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

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

ясно спасибо

Мускулдампом пользоваться - грех

тогда чем пользоваться

я слышу от каждого человека, свою версию

@i_cant_use_4_symbol_nick тогда чем пользоваться, если не mysqldump-ом

Движок муисам или иннодб?

innodb

тогда чем пользоваться

Зависит от. В среднем по больнице - иннобекапекс(хтрабекап) на иннодб. Потаблично.

Но там не очень удобное partial восстановление

я ничего не понял, что-ты написал.

😞

я знаю ток о существовании двух утлит xtrabackup и mysqldump

https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html

Считай, что это хтрабекап

с xtrabackup у меня проблемы с dev и prod окружением

так а чем она лучше? по скорости и все такое.

я xtrabackup с самого начало хотел использовать, но как? если там я работаю в docker-compose, где надо прописывать название базы данных, точно такое же, которое я использую на production. -- а еще этот проект коммититься в git, и получается часть конфига mysql, попадает в git, чего не должно быть.

у меня на локалке: mysql_name: homestead, mysql_user: homestead, mysql_pass: secret

на production, конечно все другое. ----

Смотри.

поэтому появляются проблемы с разработкой на локалке и бекапом

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

надо вернуть название базы, чтоб было такое же как на production.

Теперь я ничего не понял.

---- придется постоянно в голове помнить, что надо поменять или удалить конфиги из dokcer-compose.yml, что я буду постоянно забывать

===================== сейчас понятней распишу.

Скажи ТЗ. Минут 15 есть

Кстати

Если что, можно "бэкапиться" и снепшотами файловой системы. Но обрати внимание на кавычки

===================== сейчас понятней распишу.

Напиши, что есть и что хочешь. На высоком уровне

Без примеров и точных названий

Я разрабатываю локально (dev), где у меня есть проект с docker-compose.yml, который поднимает мое рабочее окружение с этим проектом. Там есть контейнер MariaDB, где есть envirement, благодаря которым создаются new DB и User. Я сделал работу, запушил базу на s3, с помощью innobackupex, теперь пришла пора развернуть на PROD. Но на PROD, у меня название DB совсем другое, если на (dev) я его назвал homestead, то на PROD, я его назвал my_db. --- названия баз различаются и в итоге когда я развернул, я развернул не my_db, а homestead ... который у меня был на (dev) окружении.

забавно наблюдать как два grumpy cat обсуждают серьезные вещи

innobackupex он вроде и делает, что-то типо снапшота файловой системы твоей базы.

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

забавно наблюдать как два grumpy cat обсуждают серьезные вещи

Воспитываю следующее поколение

Ваня, не рановато на пенсию собрался? )

please

Ваня, не рановато на пенсию собрался? )

Да я б с радостью уже на пенсию пошел. Да нет ещё стольких денег 😔

простите, я вас отвлек

innobackupex он вроде и делает, что-то типо снапшота файловой системы твоей базы.

Нет. Он делает бэкап базы. Мускульдамп создает "скл команды, после выполнения которых данные в базе будут как на момент дампа"

Короче, не важно)

please

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

да, я не хочу имя базы так как это конфиг, пушить в гит

да, я не хочу имя базы так как это конфиг, пушить в гит

Простой возможен? Данные на новом сервере нужны? По описанию, ты хочешь её перезатереть

ну в случаи mysqldump, такой проблемы бы не было

с такой проблемой столкнулся ток при использовании innobackupex

если буду делать dump, на локалке, то он зальет его с db name (имя базы) homestead

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

ну в случаи mysqldump, такой проблемы бы не было

С чего бы? Там первым же выражением идет DROP DATABASE IF EXIST

потом пройдет месяц, надо что-то еще сделать, возмьу бекап базы, а там название (db name) другое, и опять придется что-то придумывать. менять конфиги туда сюда

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

и логически не могй придумать как создать для этого нормальное окружение

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

так ответ-то какой: "да" или "нет"? Можно грохать прод базу?

ну допустим да

🤔

окей. Тогда я вижу три варианта. 1. Бэкапить и восстанавливать потаблично(есть несколько реализаций, но смысл один) 2. Бэкапить и ресторить полностью бд + дальнейшее переименовывание 3. (не уверен, поэтому предлагать не буду)

Но вообще, ты, наверное, хочешь не бэкапить-разворачивать базы данных, а делать миграцию.

а бекапить то как будет, с каким именем будет база

с каким именем в бекапе будет база.

так как, если я делал на local (dev), то там будет homestead к примеру

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

с каким именем в бекапе будет база.

Есть несколько вариантов, как бэкапить потаблично, но смысл в том, что ты бэкапишь _таблицы_, а значит можешь ресторить _таблицы_

1 и 2, знать бы как это выглядит

не известно же сколько гемороя там и там

:)

я про такие варианты не слышал, я скорей делал по - 2. Но у меня не переименовывается

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

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

я про такие варианты не слышал, я скорей делал по - 2. Но у меня не переименовывается

потому что переименовывать не нужно, нужно копировать. Переименовывания - это в любом случае копирование, саму команду rename database(или как она там была) выпилил ещё очень давно, под капотом было создание временных табличек, копирование в них, переключение на временные таблицы, дроп старых таблиц.

то есть копирование

Короче, юзай mysqldump :)

ты гонишь ....

ну епт

что за фигня

ты же сказал что mysqldump лучше не использовать