Kopia bazy danych MySql

Mam na serwerze kontener Dockera z bazą danych mysql.
Potrzebuje utworzyć skrypt który co 30 minut będzie tworzy kopie bazy danych 'produkcja' do bazy "produkcjaKopia"

Czat podpowiada takie rozwiązanie:

#!/bin/bash

CONTAINER_NAME="nazwa_kontenera"
DB_SOURCE="produkcja"
DB_TARGET="produkcjaKopia"
DB_USER="user"
DB_PASS="haslo"
TMP_SQL="/tmp/produkcja.sql"

echo "[$(date '+%Y-%m-%d %H:%M:%S')] --- START kopiowania bazy $DB_SOURCE ---"

# Dump całej bazy
echo "Tworzenie dumpa..."
docker exec -i $CONTAINER_NAME mysqldump -u $DB_USER -p$DB_PASS $DB_SOURCE > $TMP_SQL

# Usuń starą bazę i stwórz nową
echo "Tworzenie nowej bazy docelowej..."
docker exec -i $CONTAINER_NAME mysql -u $DB_USER -p$DB_PASS -e "DROP DATABASE IF EXISTS $DB_TARGET; CREATE DATABASE $DB_TARGET;"

# Import dumpa
echo "Import dumpa..."
docker exec -i $CONTAINER_NAME mysql -u $DB_USER -p$DB_PASS $DB_TARGET < $TMP_SQL

# Czyszczenie dumpa
rm -f $TMP_SQL

echo "[$(date '+%Y-%m-%d %H:%M:%S')] --- Kopiowanie bazy zakończone ---"

I to działa, jednak jest dosyć wolne a baza danych produkcjaKopia podpięta jest pod panel i w trakcie wykonywania kopi panel jest niedostępny przez kilkanaście sekund.
Kombinowałem aby najpierw przenosić dane do tabeli tymczasowej produkcjaKopiaTmp potem usunąć produkcjaKopia i zmienić nazwę produkcjaKopiaTmp na produkcjaKopia.
Jednak MySql nie pozwala na taką zmianę chociaż w phpMyAdmin jest taka opcja "Rename database to" i działa ona bardzo szybko.
Czy ktoś wie jak phpMyAdmin to robi? ewentualnie jak to można zrobić inaczej aby nie blokować dostępu do panelu?
Baza ma około 800 mega

Podejście z kopią bazy co 30 minut jest z grubsza złe.
IMHO nie idź tą drogą.
Jeśli chodzi o zmianę nazwy bazy to PhpMyAdmin robi to dokładnie jak opisane jest w dokumentacji
https://mariadb.com/docs/server/reference/sql-statements/data-definition/renaming-databases
Czyli tabela po tabeli jest wykonywana zmiana nazwy tabeli.
Teraz pomyśl jeśli baza urośnie Ci do 8GB i nie wystarczy Ci IO do kopiowania bazy co 30 minut. Co zrobisz?
Jak ten Twój backup wpływa na bazę produkcyjną?

Potrzebuje utworzyć skrypt który co 30 minut będzie tworzy kopie bazy danych 'produkcja' do bazy "produkcjaKopia"

Świetnie że masz klarowne wymaganie, ale mam wrażenie, że gdzieś pobłądziłeś w tworzeniu tego wymagania. Dlaczego akurat co 30 minut? Podziel się celem tego.

Jeśli szukasz backupu - czyli w razie ups chcesz odtworzyć produkcję z kopii, no to trochę bez sensu, bo spóźnisz się ~15 minut i ci skrypt zniszczy jedyną kopię.
Jeśli szukasz kopii na żywo, żeby mieć drugą identyczną bazę np. do raportowania bez obciążania głównej bazy, to prościej ustawić replikację.

To nie moje wymagania :) Jest panel gdzie user może coś zmieniać/testować czy robić cokolwiek innego. O pełnej godzinie oraz w połowie wszystko ma być zaorane i w panelu ma być przywrócony stan z produkcji

Aha, ok, no to niech będzie. Sprawdził bym najpierw, czy ta kilkunastosekundowa niedostępność nie wynika z jakiegoś locka, który zakłada mysqldump. Nie znam się na MySQL, ale widzę że jest coś takiego jak --lock-tables=false.

jurek1980 napisał(a):

Jak ten Twój backup wpływa na bazę produkcyjną?

raczej nie wpływa bo serwer na którym mam to zrobić to serwer zapasowy a tabela produkcja jest repliką bazy z serwera produkcyjnego.
Może masz jakiś pomysł jak sensownie zrealizować takie zadanie?

Mam - powiedzieć że jest to głupie zadanie i nie wykonuje się testów na danych produkcyjnych (bo po co). Test ma być testem. Nie martw się u mnie w obecnej robocie też mają takie pomysły :)
Jak musisz bo Cię zwolnią to proponuję rozważyć kopie przyrostowe i kopie bazy. Powiedzmy codziennie wykonujesz kopię głównej bazy w nocy i masz plik główny a do tego potem stosujesz kopie przyrostowe. Nie wykonujesz więc kopii całej bazy tylko masz np. 21.10-1:00 i potem 18 mniejszych lżejszych kopii do wykonywania i odtwarzania.
https://dev.mysql.com/doc/refman/8.4/en/backup-methods.html
Pamiętaj będziesz miał różnicę między silnikami czy to będzie MySQL czy MariaDB itd, więc szukaj informacji o kopiach przyrostowych dla Twojego silnika.
Ostatnia opcja, to kiedyś stosowało się jeszcze kopiowanie plików i przy kolejnym serwerze który miałby jakiś Rsync/Replikę można by go wyłączyć i spróbować kopiować dane na inżyniera Nachamowa. Dla InnoDB raczej wątpię by to działało.
Ale pogadaj w firmie wytłumacz, że to nie ma do końca sensu. Jeśli już to może potrzebujecie konkretnych tabel na tym środowisku testowym. Ja to widzę tak, że kopiujecie tam wszystko i jeśli np. macie tam jeszcze dane klientów itp to RODO i błędy typu wysłanie maili do wszystkich klientów kiedys się zdarzą. Nawet z roku temu mBank chyba wysyłał SMSy do klientów ze środowiska testowego.
A tak BTW jak odtwarzasz to do kontenera to w sumie wystarczy, że uruchomisz sobie inny kontener, w nim odworzysz dane a potem ta apliakacja nazywa przez Ciebie panelem połączy się do nowego kontenera zamiast do starego, a stary usuniesz. Może nawet jakiś Kubernetes?

jurek1980 napisał(a):

Mam - powiedzieć że jest to głupie zadanie i nie wykonuje się testów na danych produkcyjnych (bo po co). Test ma być testem. Nie martw się u mnie w obecnej robocie też mają takie pomysły :)
Jak musisz bo Cię zwolnią to proponuję rozważyć kopie przyrostowe i kopie bazy. Powiedzmy codziennie wykonujesz kopię głównej bazy w nocy i masz plik główny a do tego potem stosujesz kopie przyrostowe. Nie wykonujesz więc kopii całej bazy tylko masz np. 21.10-1:00 i potem 18 mniejszych lżejszych kopii do wykonywania i odtwarzania.
https://dev.mysql.com/doc/refman/8.4/en/backup-methods.html
Pamiętaj będziesz miał różnicę między silnikami czy to będzie MySQL czy MariaDB itd, więc szukaj informacji o kopiach przyrostowych dla Twojego silnika.
Ostatnia opcja, to kiedyś stosowało się jeszcze kopiowanie plików i przy kolejnym serwerze który miałby jakiś Rsync/Replikę można by go wyłączyć i spróbować kopiować dane na inżyniera Nachamowa. Dla InnoDB raczej wątpię by to działało.
Ale pogadaj w firmie wytłumacz, że to nie ma do końca sensu. Jeśli już to może potrzebujecie konkretnych tabel na tym środowisku testowym. Ja to widzę tak, że kopiujecie tam wszystko i jeśli np. macie tam jeszcze dane klientów itp to RODO i błędy typu wysłanie maili do wszystkich klientów kiedys się zdarzą. Nawet z roku temu mBank chyba wysyłał SMSy do klientów ze środowiska testowego.
A tak BTW jak odtwarzasz to do kontenera to w sumie wystarczy, że uruchomisz sobie inny kontener, w nim odworzysz dane a potem ta apliakacja nazywa przez Ciebie panelem połączy się do nowego kontenera zamiast do starego, a stary usuniesz. Może nawet jakiś Kubernetes?

Gdybym nie realizował dziwnych pomysłów nie bardzo miałbym co robić
w bazie nie ma danych osobowych tylko jakieś wyliczenia, nie ma też tasków które mogły by coś namieszać.
Podoba mi się to co napisałeś na końcu, stworzyłem skrypt który tworzy kontener tymczasowy, kopiuje wszystkie pliki do niego z kontenera gdzie jest baza i potem zmieniam nazwę kontenera tymczasowego. Podepnę ten panel pod tą kopie.
Samo kopiowanie plików między kontenerami trwa jakieś 10 sekund, pytanie czy w tym czasie nic nie będzie się działo z replikacją bazy z produkcji?