Немного про бекапы базы и почему mariadb - зло.

[Yoda]

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

 

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

В итоге ситуация: есть актуальная база со всеми данными (заказы, категории, статьи) но без товаров, случайно есть живой тестовый сфинкс-индекс на стороннем сервере, в котором есть все актуальные данные о товарах кроме опций и совершенно случайно у меня оказался недокачанный почти актуальный дамп базы, без таблиц oc_product_to_category (видимо при экспорте я встрял в timelimit php или wait_timeout базы или в какое еще ограничение, вобщем большие базы из phpmyadmin экспортить-импортить - зло. Консоль и mysqldump  - наше все).

 

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

 

Как мы вышли из ситуации. 

 

1 - сохранили на всякий случай оставшуюся базу без товаров.

2 - подняли рядом мой недокачанный дамп трехдневной несвежести.

3 - убили все таблицы связанные с товарами из актуальной базы 

4 - экспортировали в отдельный sql-файл эти же таблицы из моего дампа (без таблиц product_to_category, product_to_layout и product_to_store).

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

6 - тупыми запросами создали product_to_layout и product_to_store. Благо у нас один магазин и один айди схемы товаров.

 

И казалось бы можно радоваться все завелось. Но не тут то было. 
Работало ровно то, что уже было в базе а вот добавить мы не могли ни опцию, ни товар, ни атрибут....

 

Вопрос знатокам: почему, и как с этим бороться?

 

 

[auditor]

так а mariadb тут при чем ?

[splka]

1. Пишется скрипт, вешается в крон и бекапы потом пушатся куда угодно, без лишних телодвижений.
Семпл вот такой примерно:

DBLIST=`mysql -ulogin -ppassword-ANe"SELECT GROUP_CONCAT(schema_name) FROM information_schema.schemata WHERE schema_name NOT IN ('information_schema','performance_schema')" | sed 's/,/ /g'`
MYSQLDUMP_OPTIONS="-uroot -pPASSWORD --single-transaction --routines --triggers"
BACKUP_DEST=/root/backup/sql-backup/`date +\%G-\%m-\%d`
BACKUPDIR="sql-backup"
BACKUPDATE=`date +\%G-\%m-\%d`
mkdir ${BACKUP_DEST}
for DB in `echo "${DBLIST}"`
do
    mysqldump ${MYSQLDUMP_OPTIONS} ${DB} | gzip -c -9 > ${BACKUP_DEST}/${DB}.sql.gz      &
done
wait

2. Таким же тупым скриптом завести нулевые значения аттрибутов для каждого товара не?
И потом заполнить.

[spectre]

Наверное просто в недокачанном дампе не оказалось primary ключей и автоинкремента, сам пару раз так лажанулся )

[MrGeek]

Решительно не понимаю, в чём проблема с MariaDB? Во-первых, с точки зрения пользователя, это тот же MySQL, только в левой руке и в профиль. Во-вторых, есть куча утилит для бэкапа MariaDB без лишних телодвижений, например, тот же Handy Backup.

[Yoda]

Лучший бекап базы это mysqldump. А ещё лучший из остановленной Slave реплики.

Зло в mariadb, в том, что дамп из mysql сразу создает индексы. А из mariadb после набора данных. И если в процессе импорта что-то пошло не так, а вы этого не заметили, прощайте автоинкрементальные поля.

В умелых руках mariadb работает быстрее и с в версии 10.3 содержит кучу полезных ништяков. Но в целом новичкам лучше пользоваться mysql 5.7 

[ocdev_pro]

В 25.11.2020 в 13:03, Yoda сказал:

Лучший бекап базы это mysqldump. А ещё лучший из остановленной Slave реплики.

Зло в mariadb, в том, что дамп из mysql сразу создает индексы. А из mariadb после набора данных. И если в процессе импорта что-то пошло не так, а вы этого не заметили, прощайте автоинкрементальные поля.

В умелых руках mariadb работает быстрее и с в версии 10.3 содержит кучу полезных ништяков. Но в целом новичкам лучше пользоваться mysql 5.7 

ИМХО никогда не использую mariadb на проектах с нуля. Только Percona и InnoDB engine