Pomoc Mariadb w kontenerze i katalog na bazy

[pepus]

Dzień doberek.

Na początek powiem tak, to mój pierwszy kontener, a jeśli chodzi o sql'a jestem zielony jak szczypiorek na wiosnę, ale znam to forum, znam googla,
poczytałem, założyłem, działa, lecz mam jeden problem z którym sobie nie radzę...
Założenia: kontener mariadb w pierwszej puli dyskowej (dysk systemowy SSD), bazy trzymane poza kontenerem w drugiej puli dyskowej (raid hdd)

Co już mam:
założyłem kontener z bazą mariadb:

 docker run -d --name mariadb-prov --restart=always -e MARIADB_ROOT_PASSWORD=abcd -v /share/CACHEDEV2_DATA/Kontener/dane:/var/lib/mysql -p 3306:3306 mariadb:latest

działa, Wolumin założony jest tam gdzie lądują kontenery czyli
"/share/CACHEDEV1_DATA/Container/container-station-data/"
kontener ładnie działa, do bazy łączę się Heidisql.
moje dane teoretycznie zgodnie z -v dane powinny być w katalogu "dane" na CACHEDEV2_DATA, na ale
z heidi rozpakowałem bazę i wylądowała wewnątrz kontenera czyli w katalogu CACHEDEV1_DATA

robiąc inspekcję otrzymuję w sekcji Mouts:

$ docker container inspect mariadb-prov

 "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/mysql",
                "Destination": "/share/CACHEDEV2_DATA/Kontener/dane",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            },
            {
                "Type": "volume",
                "Name": "52fd82140bc0b3b169bb2ada079e101844fcfaac242b3bddc76b1eb608c7dfc3",
                "Source": "/share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/52fd82140bc0b3b169bb2ada079e101844fcfaac242b3bddc76b1eb608c7dfc3/_data",
                "Destination": "/var/lib/mysql",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],

przez ssh łączę się i moje wymarzone "CACHEDEV2_DATA/Kontener/dane" to tak jakby całkowicie niezależny katalog od tego gdzie wylądowała aktualnie moja baza.
No i pytanie:
Jak sprawić by moja baza była trzymana tam gdzie ja chcę?

--
Pozdrawiam oczekująco


Wersja oprogramowania Firmware: 5.0.0.1858
Model serwera: QNAP TS-743A

 

[Usunięty użytkownik pigers]

nie można wystawić tej samej ścieżki kontenera do wolumenu i do binda - docker krzyczy że nie można tak odpalić kontenera
zrób restart tego kontenera i co się dzieje ?

 

[jerry1333]

U mnie działa

[~] # mkdir /share/Public/mysql-data
[~] # docker run -d --name mariadb-prov --restart=always -e MARIADB_ROOT_PASSWORD=abcd -v /share/Public/mysql-data/:/var/lib/mysql -p 3306:3306 mariadb:latest
Unable to find image 'mariadb:latest' locally
latest: Pulling from library/mariadb
7b1a6ab2e44d: Pull complete
034655750c88: Pull complete
f0b757a2a0f0: Pull complete
4bbcce26bc5e: Pull complete
04f220ee9266: Pull complete
89c8a77f7842: Pull complete
d1de5652303b: Pull complete
ef669123e59e: Pull complete
e5cec468d3a6: Pull complete
b14b1ba1d651: Pull complete
Digest: sha256:0f04ae6f30c5a3295fb7cc9be5780c15ff21d6028f999b19f5803114c1e8559e
Status: Downloaded newer image for mariadb:latest
f42fba38e2ca0a82374e8f89b03c75f9a70510eb038c1c01b0178e3c68d1c39e
[~] # docker container inspect mariadb-prov
...
        "HostConfig": {
            "Binds": [
                "/share/Public/mysql-data/:/var/lib/mysql"
            ],
...
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/share/Public/mysql-data",
                "Destination": "/var/lib/mysql",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
...
[~] # ls /share/Public/mysql-data/
aria_log.00000001  ddl_recovery.log  ibdata1	  ibtmp1	    mysql/		  sys/
aria_log_control  ib_buffer_pool    ib_logfile0  multi-master.info  performance_schema/

Katalog w którym chcesz umieścić bazy istnieje? Masz do niego prawa zapisu (albo czy docker ma)?

 

[Usunięty użytkownik pigers]

-v /share/Public/mysql-data/:/var/lib/mysql

no ale to przecież bind , nie wolumen!

z heidi rozpakowałem bazę i wylądowała wewnątrz kontenera czyli w katalogu CACHEDEV1_DATA

popraw export ? skoro dane są w /var/lib/mysql .. to muszą tam wylądować

 

[pepus]

Jerry, dzięki za sprawdzenie,
Pigers, Teraz nie mam dostępu. Sprawdzę w poniedziałek.

 

[jerry1333]

no ale to przecież bind , nie wolumen!

I? Jakie ma to znaczenie w kontekście tego co chce osiągnąć?

z heidi rozpakowałem bazę

A Heidi nie robi przypadkiem dumpa jako sql?

 

[Usunięty użytkownik pigers]

moim zdaniem export został zrobiony poza wolumen - więc urósł kontener , działanie poprawne

PS: Zrestartuj ten kontener, to stracisz dane.

 

[jerry1333]

PS: Zrestartuj ten kontener, to stracisz dane.

• Utworzenie kontenera
• Dodanie nowej bazy danych w heidisql, tam stworzenie niej tabeli i dodanie danych do tabeli
• restart kontenera
• Dane ciągle są na swoim miejscu (baza danych, tabela, dane w tabeli)
• usunięcie całęgo kontenera oraz obrazu użytego do jego stworzenia
• utworzenie na nowo kontenera
• Dane ciągle są na swoim miejscu (baza danych, tabela, dane w tabeli)

Wniosek: nawet przypadkowe usunięcie kontenera nie skasowało baz danych.

[~] #  docker run -d --name mariadb-prov --restart=always -e MARIADB_ROOT_PASSWORD=abcd -v /share/Public/mysql-data/:/var/lib/mysql -p 3306:3306 mariadb:latest
Unable to find image 'mariadb:latest' locally
latest: Pulling from library/mariadb
7b1a6ab2e44d: Pull complete
034655750c88: Pull complete
f0b757a2a0f0: Pull complete
4bbcce26bc5e: Pull complete
04f220ee9266: Pull complete
89c8a77f7842: Pull complete
d1de5652303b: Pull complete
ef669123e59e: Pull complete
e5cec468d3a6: Pull complete
b14b1ba1d651: Pull complete
Digest: sha256:0f04ae6f30c5a3295fb7cc9be5780c15ff21d6028f999b19f5803114c1e8559e
Status: Downloaded newer image for mariadb:latest
eeab2f9535482b66fa95e9679c6f830dcab22ecc89d7fe0fc6dcbd6a1d9aea45
[~] # ls /share/Public/mysql-data/
aria_log.00000001  aria_log_control  ddl_recovery-backup.log  ddl_recovery.log	ib_buffer_pool	ibdata1  ib_logfile0  ibtmp1  multi-master.info  mysql/  nowy-plik.log	performance_schema/  sys/  TEST_QNAP_FORUM/
[~] # docker restart mariadb-prov
mariadb-prov
[~] # docker rm mariadb-prov -v -f
mariadb-prov
[~] # docker image rm mariadb
Untagged: mariadb:latest
Untagged: mariadb@sha256:0f04ae6f30c5a3295fb7cc9be5780c15ff21d6028f999b19f5803114c1e8559e
Deleted: sha256:e2278f24ac88b82f98ef58de4bf15c0b01df3de2f1fe835e2ea4350282d58700
Deleted: sha256:11e9bf96045889878ecb28fc7431af359878f2fa0bc9fcfd7a21de09feab2385
Deleted: sha256:3331ebe71406c0131f5a462951b87ad96d80d3d07ec309a2b40c8bbc6062e0ce
Deleted: sha256:98fef66422fa8c83ef6cd25f69bf3c1df1115b91c77cfdc1c0b82439fa4b48b8
Deleted: sha256:74481f47fb22da394bea6c7b0707f2fd01e888ba16c4f48c4805803d7f32830b
Deleted: sha256:ec96296944cc11a30b365e74768b5e8726e93cc2ab755a0ead282c66513591d5
Deleted: sha256:9ef89e12d1987b0b7d8081e1ecb9e868d00cc98b8783d816024f77fae996ce87
Deleted: sha256:fe65ce8f5cef9bd16097dd6b9b2484e6710a2ea3c5c2e948f16ceff5002d3c3f
Deleted: sha256:715a1b962166ede06c7a0e87d068a4b686e6066e0eca5ecab6f4d6cfab2121fe
Deleted: sha256:97ab3baee34d0c75ee10e65c63a06cbc87d20d695c17d14ad565d4ff1b8dc2ca
Deleted: sha256:9f54eef412758095c8079ac465d494a2872e02e90bf1fb5f12a1641c0d1bb78b
[~] #  docker run -d --name mariadb-prov --restart=always -e MARIADB_ROOT_PASSWORD=abcd -v /share/Public/mysql-data/:/var/lib/mysql -p 3306:3306 mariadb:latest
Unable to find image 'mariadb:latest' locally
latest: Pulling from library/mariadb
7b1a6ab2e44d: Pull complete
034655750c88: Pull complete
f0b757a2a0f0: Pull complete
4bbcce26bc5e: Pull complete
04f220ee9266: Pull complete
89c8a77f7842: Pull complete
d1de5652303b: Pull complete
ef669123e59e: Pull complete
e5cec468d3a6: Pull complete
b14b1ba1d651: Pull complete
Digest: sha256:0f04ae6f30c5a3295fb7cc9be5780c15ff21d6028f999b19f5803114c1e8559e
Status: Downloaded newer image for mariadb:latest
d7245785342350cae52c3daa2c9e0f86abca230b62d28f9d04637bcace2e8a83
[~] # ls /share/Public/mysql-data/
aria_log.00000001  aria_log_control  ddl_recovery-backup.log  ddl_recovery.log	ib_buffer_pool	ibdata1  ib_logfile0  ibtmp1  multi-master.info  mysql/  nowy-plik.log	performance_schema/  sys/  TEST_QNAP_FORUM/

 

[Usunięty użytkownik pigers]

z heidi rozpakowałem bazę i wylądowała wewnątrz kontenera czyli w katalogu CACHEDEV1_DATA

Dodanie nowej bazy danych w heidisql, tam stworzenie niej tabeli i dodanie danych do tabeli

mam wątpliwość że to te same czynności

 

[jerry1333]

z heidi rozpakowałem bazę i wylądowała wewnątrz kontenera czyli w katalogu CACHEDEV1_DATA

Dodanie nowej bazy danych w heidisql, tam stworzenie niej tabeli i dodanie danych do tabeli

mam wątpliwość że to te same czynności

No na 100% nie te same, nawet jeśli zrobił dumpa bazy to na 99.99% jest to w postaci SQL-a i samo wrzucenie tego pliku / plików do katalogu /var/... nic nie da

 

[Usunięty użytkownik pigers]

moje dane teoretycznie zgodnie z -v dane powinny być w katalogu "dane" na CACHEDEV2_DATA, na ale
z heidi rozpakowałem bazę i wylądowała wewnątrz kontenera czyli w katalogu CACHEDEV1_DATA

to powiedz mi skąd ten temat i wyjaśnij powyższe

 

[jerry1333]

 

[pepus]

Dzień doberek.

Panowie, przede wszystkim dzięki za pochylenie się nad moim tematem.
pół dnia się doktoryzowałem, i takie wnioski:
1. Założenie kontenera z palca - ścieżki są poprawne, zakładanie plików/katalogów w kontenerze, albo w mojej lokalizacji, działa ok.
2. Założenie kontenera przez portainer działa OK. jw.
sprawdzenie: inspektem

  "Mounts": [
            {
                "Type": "bind",
                "Source": "/share/CACHEDEV2_DATA/Kontener/dane",
                "Destination": "/var/lib/mysql",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
        "Config":................

Wychodzi na to że -v - tworzy bind a nie volumen no i tak to widać:
wchodzę w ContainerStation w zakładki, obraz -> jest, Wolumin ->nie ma, kontener -> jest i działa.
No i zachciało mi się zmienić ustawienia.
I tu jest "pies pogrzebany". Wlazłem do ustawień kontenera przez ContainerStation żeby np. ustawić limit procka, albo pamięci albo cokolwiek, i tam na dole jest taki checkbox - "aby zastosować te ustawienia, uruchom ponownie kontener". I w tym momencie ContainerStation zakłada sobie Wolumin w lokalizacji domyślnej (u mnie "/share/CACHEDEV1_DATA/....." dopisuje sobie do sekcji Mounts ten wolumin

  "Mounts": [
            {
                "Type": "volume",
                "Name": "5fa3d3987462ba16afc3fa2555c9828b11485a03987414ed8d13f2826d6afc2e",
                "Source": "/share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/5fa3d3987462ba16afc3fa2555c9828b11485a03987414ed8d13f2826d6afc2e/_data",
                "Destination": "/var/lib/mysql",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            },
            {
                "Type": "bind",
                "Source": "/var/lib/mysql",
                "Destination": "/share/CACHEDEV2_DATA/Kontener/dane",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
        "Config": ................

No i pozamiatane
moja lokalizacja (bind) przestaje działać.
czytając Use volumes nie ma możliwości zakładania wolumenu w dowolnej ścieżce.
więc na razie zostaje bind i chroń mnie Panie przed wejściem w ustawienia

Dzięki.

 

[Usunięty użytkownik pigers]

super ! czyli mamy kolejny babol !

zgłaszaj i ścigaj helpdesk do ich śmierci :>

czyli dalej QNAP wie lepiej (patrz bootowanie PXE w stacji wirtualizacji - dokładnie taka sama sytuacja)

 

[pepus]

To jeszcze tylko dodam że: wchodząc w te ustawienia kontenera kilka razy, coś tam zmieniam i zawsze "zastosuj" - to za każdym razem tworzy nowy wolumen, i za każdym razem ściąga nowy obraz :latest-1, :latest-2, itd...

Jak dla mnie temat zakończony.