Etykiety

linux (14) php (14) Laravel (9) mysql (9) Hardware (8) Windows (6) sieci (5) PowerShell (4) software (4) MariaDB (3) apache (3) html (3) Microsoft (2) bezpieczeństwo LAN (2) cygwin (2) Akcesoria (1) CMS (1) Laptop (1) Open Office (1) drupal 7 (1) gpg (1) hosting (1) jquery (1) sieci LAN (1) xml (1) zabezpieczenie sieci LAN (1)

sobota, 31 grudnia 2016

MariaDB - Widoki

Widoki MariaDB - Wstęp


Podstawowym celem tego tutorialu jest omówienie podstaw widoków w MariaDB. Zobaczymy czym są widoki i do czego mogą się one nam przydać. Powiem wstępnie, iż widoki są tworzone na podstawie polecenia SELECT. Nazwy utworzonych widoków widnieją w bazie danych analogicznie do nazw istniejących tam tabel, ponieważ tabele i widoki dzielą się tą samą przestrzenią nazw. Po ich utworzeniu widoki mogą być modyfikowane lub usuwane, podobnie jak tabele.

MariaDB - Widoki
MariaDB

Praca z widokami wymaga gruntownej wiedzy z zakresu formułowania zapytań MySQL, a także z zakresu struktury tabel. Zobaczymy, że widoki MariaDB są potężnym i bardzo przydatnym narzędziem.

Dla lepszego zrozumienia zagadnienia widoków przygotowałem przykładowe tabele i wprowadziłem do nich wiersze danych.

Oto moje przykładowe tabele, zawierające tylko potrzebne dla niniejszego tutorialu kolumny, symulujące fragment bazy danych, powiedzmy jakiegoś rodzaju sklepu:
MariaDB [tests]> show tables; +-----------------+ | Tables_in_tests | +-----------------+ | cennik | | kontrahenci | | zakupy | +-----------------+ 4 rows in set (0.00 sec)

Tabela `cennik` jest cennikiem produktów. Zakładając, dla naszego przykładu, że ceny produktów są aktualizowane codziennie i w danym dniu dla każdego produktu może być wyłącznie jedna cena, utworzyłem odpowiedni klucz UNIQUE:
CREATE TABLE `cennik` ( `produkt` smallint(5) unsigned NOT NULL,> `cena_netto` decimal(6,2) NOT NULL, `data` date NOT NULL, UNIQUE KEY `produkt` (`produkt`,`data`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Wprowadzamy przykładowe dane do tabeli `cennik`:
MariaDB [tests]> insert into cennik values(1,10.15,"2016-03-03"),(1,10.16,"2016-03-04"),(2,10.15,"2016-03-03"),(2,11.16,"2016-03-04");

Tabela `kontrahenci`, jak sama nazwa sugeruje, zawiera dane osobowe kontrahentów, czyli klientów dokonujących zakupy w sklepie:
CREATE TABLE `kontrahenci` ( `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT, `imie` varchar(15) DEFAULT NULL, `nazwisko` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8

Wprowadzamy przykładowe dane do tabeli `kontrahenci`:
MariaDB [tests]> insert into kontrahenci (imie, nazwisko) values("Jan","Kowalski"),("Janusz", "Kowal");

Tabela zakupy zawiera informacje o zakupionych produktach i prezentuje się następująco:
CREATE TABLE `zakupy` ( `produkt` smallint(5) unsigned NOT NULL, `kontrahent` smallint(5) unsigned NOT NULL, `data` date NOT NULL, `ilosc` smallint(5) unsigned NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8

A oto przykładowe dane dla powyższej tabeli:
MariaDB [tests]> insert into zakupy values(1,1,"2016-03-03",3), (2,1,"2016-03-03",1),(1,1,"2016-03-04",3),(1,2,"2016-03-04",6);

Nasze tabele zawierają już jakieś informacje o dokonanych w naszym sklepie zakupach ;-) Załóżmy teraz, że chcemy się dowiedzieć, ile w sumie wydali klienci każdego dnia, kupując produkty w naszym sklepie. Aby uzyskać tego typu informacje wykonujemy następujące zapytanie:
MariaDB [tests]> select concat(kontrahenci.imie, ' ',kontrahenci.nazwisko) as klient, sum(cennik.cena_netto * zakupy.ilosc) as razem, zakupy.data from kontrahenci cross join zakupy on (zakupy.kontrahent = kontrahenci.id) left join cennik on (cennik.produkt = zakupy.produkt and cennik.data = zakupy.data) group by kontrahenci.id, zakupy.data; +--------------+-------+------------+ | klient | razem | data | +--------------+-------+------------+ | Jan Kowalski | 40.60 | 2016-03-03 | | Jan Kowalski | 30.48 | 2016-03-04 | | Janusz Kowal | 60.96 | 2016-03-04 | +--------------+-------+------------+ 3 rows in set (0.00 sec)

Zapytanie jest już samo w sobie nieco złożone.

Widoki MariaDB - Podstawowe koszyści


Mają na uwadzę powyżej przedstawione zapytanie i zakładając, iż mamy zamiar generować podobne raporty dość często, a na dodatek chcemy mieć możliwość filtrowania uzyskiwanych w ten sposób informacji, np. na podstawie zakresów dat, wówczas sprawy się nieco bardziej komplikują. Załóżmy również, że powyższe zapytanie ma być częścią kodu php aplikacji web, obsługującej nasz sklep internetowy. W przypadku konieczności modyfikacji struktury naszych tabeli, konieczna może stać się ingerencja w skrypty php zawierające zapytania SQL. Tutaj właśnie przychodzą nam z wielką pomocą widoki, nie tylko dlatego, iż mogą one uprościć nasze zapytania SQL, ale także dlatego, iż mogą one stanowić dodatkową programistyczną warstwę abstrakcyjną pomiędzy aplikacją web a właścimym zapytaniem SQL, co daje programistom dodatkową elastyczność. Jednak widoki mogą nam ułatwić wiele innych zadań. O tym napiszę w dalszej części tego artykułu.

Przed przejściem do dalszej części tego artykułu warto zapoznać się z poleceniem CREATE VIEW Wyjaśniam, że stosowana w naszym przykładzie składnia, zawierająca 'sql security invoker' oznacza iż dostęp do utworzonego widoku ma mieć miejsce z uprawnieniami, jakie posiada użytkownik wywołujący widok. Oznacza to, iż w przykładowym przypadku wywołania widoku przez osobę nie posiadającą uprawnień do tabeli `cennik`, zostanie wygenerowany błąd.

Zobaczmy teraz jak działają widoki w praktyce! Pamiętajmy o tym, iż do tworzenia widoków musimy posiadać uprawnienia CREATE VIEW do tabeli, które mają być objęte widokiem. Aby rozpocząć utwórzmy widok na podstawie naszego poprzedniego zapytania SQL. Robi się to przykładowo w ten oto sposób:
MariaDB [tests]> create sql security invoker view zakupy_wedlug_daty as select concat(kontrahenci.imie, ' ',kontrahenci.nazwisko) as klient, sum(cennik.cena_netto * zakupy.ilosc) as razem, zakupy.data from kontrahenci cross join zakupy on (zakupy.kontrahent = kontrahenci.id) left join cennik on (cennik.produkt = zakupy.produkt and cennik.data = zakupy.data) group by kontrahenci.id, zakupy.data; Query OK, 0 rows affected (0.03 sec)

Nowy widok jest dostępny w tej samej przestrzeni nazw co tabele:
MariaDB [tests]> show tables; +--------------------+ | Tables_in_tests | +--------------------+ | cennik | | kontrahenci | | zakupy | | zakupy_wedlug_daty | +--------------------+ 5 rows in set (0.00 sec)

Możemy już teraz zacząć korzystać z nowo utworzonego widoku:
MariaDB [tests]> select * from zakupy_wedlug_daty; +--------------+-------+------------+ | klient | razem | data | +--------------+-------+------------+ | Jan Kowalski | 40.60 | 2016-03-03 | | Jan Kowalski | 30.48 | 2016-03-04 | | Janusz Kowal | 60.96 | 2016-03-04 | +--------------+-------+------------+ 3 rows in set (0.00 sec)

Jak widać, wyniki powyższego zapytania są analogiczne do wyników naszego poprzedniego, bardziej złożonego zapytania, ponieważ widok został utworzony właśnie na jego podstawie, lecz nasze zapytanie jest teraz o wiele prostsze niż poprzednie, co daje większą swobodę i przejrzystość! W takiej sytuacji, możemy w prosty sposób dodawać kolejne warunki do naszego zapytania. Na przykład:
MariaDB [tests]> select * from zakupy_wedlug_daty where data between "2016-03-02" and "2016-03-03" and klient like "%Kowalski"; +--------------+-------+------------+ | klient | razem | data | +--------------+-------+------------+ | Jan Kowalski | 40.60 | 2016-03-03 | +--------------+-------+------------+ 1 row in set (0.00 sec)

Jak wspomniałem wcześniej, dodatkowym atutem widoków, jest ich programistyczna warstwa abstrakcyjna w przypadku aplikacji zawierających zapytania SQL. Jeśli w naszych aplikacjach stosujemy widoki, modyfikacje struktury tabeli nie niosą za sobą konieczności dopasowania zapytań SQL obecnych w aplikacji! Jedyne co może być w takim przypadku konieczne, będzie dopasowanie widoku, a można to przykładowo zrobić za pomocą polecenia ALTER VIEW.
Aby sprawdzić, w jaki sposób został utworzony dany widok, można wydać polecenie SHOW CREATE VIEW, przykładowo:
MariaDB [tests]> show create view zakupy_wedlug_daty;

Ciekawostką, o której warto tutaj wspomnieć, jest to, iż widoki mogą być tworzone nie tylko na podstawie zapytań obejmujących tabele, lecz zapytania te mogą obejmować także widoki!
Widoki usuwamy za pomocą polecenia DROP VIEW.

Widoki - Dodatkowe korzyści


Widoki w MariaDB to cudowne narzędzie! Oprócz omówionych wcześniej korzyści, stosowanie widoków daje nam możliwość ograniczenia dostępności poufnych informacji. Załóżmy, że tabela kontrahenci zawiera o wiele więcej kolumn niż imię i nazwisko, a są to przykładowo kolumny takie jak numer pesel, czy numery kart kredytowych. Załóżmy również, że użytkownik widoku ma mieć możliwość formułowania zapytań obejmujących wyłącznie wybrane kolumny tej tabeli. Staje się jasne, jak przydatne są tutaj widoki! Możemy w ten sposób tworzyć różne widoki, oparte na tych samych tabelach, lecz umożliwiające dostęp wyłacznie do wybranych kolumn tych tabel, w zależności od rodzaju dostępu do informacji, jaki mamy zamiar przydzielić użytkownikom tych widoków.

Dodatkowym atutem stosowania widoków, w przypadku baz danych złożonych z wielu tabel, w których występują bardzo złożone relacje danych, jest możliwość tworzenia idealnie zoptymalizowanych zapytań zawierających różnego rodzaju skomplikowane łączenia i udostępniania ich mniej doświadczonym użytkownikom, w celu ograniczenia obciążeń serwera wynikających z nieodpowiednio sformułowanych zapytań.

Mam nadzieję, iż niniejszy tutorial okaże się pomocny. W przypadku pytań proszę o komentarze :-)

czwartek, 29 grudnia 2016

Serwer DHCP Linux - Podstawowa konfiguracja

Serwer DHCP umożliwia automatyczne przydzielanie adresów IP klientom sieciowym obsługującym ten protokół, ale jego rola nie kończy się na tym zadaniu. Wraz z adresem IP, maszyny klienckie moga otrzymywać wiele innych informacji związanych ze środowiskiem sieciowym, takich jak adresy routerów, adresy serwerów DNS, adresy serwerów WINS i wiele innych. W ten sposób użytkownicy poszczególnych komputerów w sieci, nie muszą ani znać, ani recznie wprowadzać tych informacji w ustawieniach interfejsów sieciowych swoich maszyn. Jest to szczególnie pożyteczne w rozległych sieciach, w których znajduje się duża ilość komputerów.

W tym tutorialu, pierwszym z serii poświęconej zagadnieniom DHCP / BIND, ograniczam się do wyjaśnienia jak uruchomić, z podstawowymi ustawieniami konfiguracyjnymi, serwer DHCP na maszynach pracujących pod kontrolą systemów Red Hat Linux, Fedora lub Centos. Choć w większości innych dystrybucji systemu Linux konfiguracja sewera DHCP przebiega analogicznie, występują tam pewne różnice związane z pozostałymi kwestiami poruszanymi w tym tutorialu.

Zobaczmy teraz jak pozyskać, zainstalować i skonfigurować pakiet oprogramowania serwera DHCP.

Przed rozpoczęciem, na maszynie na której mamy zamiar zainstalować serwer DHCP, należy ustawić stały adres IP dla interfejsu sieciowego, obsługującego sieć, dla której mamy zamiar skonfigurować oprogramowanie. Aby to zrobić należy edytować odpowiedni skrypt konfiguracyjny interfejsu sieciowego, domyślnie noszący nazwę interfejsu z prefiksem ifcfg-.

Skrypty zawierające konfiguracje interfejsów sieciowych znajdują się w lokalizacji:
/etc/sysconfig/network-scripts/
Ponieważ w naszym przykładzie interfejs sieciowy nosi nazwę enp6s0, plik zawierający ustawienia konfiguracyjne to odpowiednio:
/etc/sysconfig/network-scripts/ifcfg-enp6s0
Konfiguracja interfejsu sieciowego, dla którego ma zostać uruchomiony serwer DHCP, powinna uwzględniać ustawienie stałego adresu IP. Dla naszego przykładu będzie to adres klasy C:
TYPE=Ethernet NAME=enp6s0 ONBOOT=yes HWADDR=10:43:54:E2:CC:18 IPADDR=192.168.0.7 NETMASK=255.255.255.0 GATEWAY=192.168.0.1
Jeśli stały adres IP dla naszego interfejsu nie jest jeszcze ustawiony, warto to zrobić przez przejściem do kolejnego kroku. Należy oczywiście ustawić adres IP należący do podsieci, która ma być obsługiwana przez nasz serwer DHCP, zgodnie z ustawieniami w pliku konfiguracyjnym dhcpd.conf, o którym będzie mowa troszkę dalej.

Po dostosowaniu ustawień interfejsu sieciowego należy zrestartować usługi sieciowe:
[root@amanda ~]# systemctl restart network
Warto teraz upewnić się, że sieć działa jak neleży:
[root@amanda ~]# systemctl status network ● network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled) Active: active (exited) since Sun 2016-12-25 21:46:32 CET; 3 days ago Docs: man:systemd-sysv-generator(8) Dec 25 21:46:31 amanda systemd[1]: Starting LSB: Bring up/down networking... Dec 25 21:46:32 amanda network[1207]: Bringing up loopback interface: [ OK ] Dec 25 21:46:32 amanda network[1207]: Bringing up interface enp6s0: [ OK ] Dec 25 21:46:32 amanda systemd[1]: Started LSB: Bring up/down networking. Hint: Some lines were ellipsized, use -l to show in full.
Jeśli usługi sieciowe działają prawidłowo, możemy przejść do instalacji pakietu zawierającego serwer DHCP:
[root@amanda ~]# yum install dhcp
Następnie, przed uruchomieniem serwera DHCP, należy wprowadzić ustawienia konfiguracyjne w pliku dhcpd.conf. Plik dhcpd.conf jest miejscem, w którym określamy co nasz serwer ma robić i jak ma to robić. Może on zawierać rozmaite ustawienia i opcje. Jest tego naprawdę bardzo dużo. Tych, którzy chcieliby już teraz zapoznać się ze wszystkimi możliwościami konfiguracji serwera DHCP, zachęcam do przeczytania manuala dhcpd.conf a także manuala opcji dhcpd.conf. Dla niniejszego przykładu wystarczą jednak poniższe, podstawowe i proste ustawienia:
option routers 192.168.0.1; default-lease-time 600; max-lease-time 7200; authoritative; log-facility local7; subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.170 192.168.0.180; } host maszyna_janka { hardware ethernet 91:12:e9:a7:97:7b; fixed-address 192.168.0.100; } host hp2055dn { hardware ethernet 00:22:5e:8E:94:61; fixed-address 192.168.0.108; }
A oto znaczenie powyższych ustawień:

option-routers: opcja pozwala określić listę routerów znajdujących się w obsługiwanej podsieci. Jeśli routerów jest więcej, wówczas należy je oddzielić przecinkami;

default-lease-time: ustawienie pozwala określić domyślną wartość czasu ważności przydziału, wyrażoną w sekundach, dla przydziałów, dla których klient nie żąda konkretnego czasu ważności;

max-lease-time: uswtawienie pozwala określić maksymalną wartość czasu przydziału, wyrażoną w sekundach;

authoritative: ustawienie to oznacza, iż serwer DHCP jest autorytatywny dla obsługiwanych podsieci;

log-facility: ustawienie określa sposób prowadzenia dzienników zdarzeń;

subnet: ustawienie pozwala zdefiniować obsługiwane przez serwer podsieci, w których pula przydzielnych adresów IP określana jest słowem kluczowym range;

host: ustawienie umozliwiające zdefiniowanie stałych adresów IP dla maszych znajdujących się w obsługiwancyh podsieciach. Adresy te powinny jednak znajdować się poza zakresami puli przydzielnych adresów;

Przed przystąpieniem do uruchomienia serwera DHCP, warto sprawdzić, czy plik dhcpd.conf nie zawiera błędów, a można to zrobić w następujący sposób:
[root@amanda ~]# dhcpd -t -cf /etc/dhcp/dhcpd.conf Internet Systems Consortium DHCP Server 4.2.5 Copyright 2004-2013 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Uruchamiamy serwer dhcp i sprawdzamy jego status:
[root@amanda ~]# systemctl status dhcpd ● dhcpd.service - DHCPv4 Server Daemon Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2016-12-29 16:44:42 CET; 3min 15s ago Docs: man:dhcpd(8) man:dhcpd.conf(5) Main PID: 25995 (dhcpd) Status: "Dispatching packets..." CGroup: /system.slice/dhcpd.service └─25995 /usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid Dec 29 16:44:42 amanda dhcpd[25995]: Wrote 0 leases to leases file. Dec 29 16:44:42 amanda dhcpd[25995]: Listening on LPF/enp6s0/00:23:54:f2:cc:18/192.168.0.0/24 Dec 29 16:44:42 amanda dhcpd[25995]: Sending on LPF/enp6s0/00:23:54:f2:cc:18/192.168.0.0/24 Dec 29 16:44:42 amanda dhcpd[25995]: Sending on Socket/fallback/fallback-net Dec 29 16:44:42 amanda systemd[1]: Started DHCPv4 Server Daemon. Dec 29 16:45:40 amanda dhcpd[25995]: DHCPREQUEST for 192.168.0.111 (192.168.0.6) from 90:02:a9:c5:27:24 via enp6s0: unknown lease 192.168.0.111.
Jeśli chcemy, aby serwer automatycznie się uruchamiał przy starcie systemu, wówczas należy wykonać następujący krok:
[root@amanda ~]# systemctl enable dhcpd Created symlink from /etc/systemd/system/multi-user.target.wants/dhcpd.service to /usr/lib/systemd/system/dhcpd.service.
Na tym etapie możemy już ustawić maszyny klienckie, do automatycznego pozyskiwania adresów IP. Przykładowo w systemach Windows można to zrobić w następujący sposób:


Automatyczne uzyskiwanie adresu IP - Windows
Automatyczne uzyskiwanie adresu IP w systemie Microsoft Windows

Aby sprawdzić aktualny stan przydziałów, po stronie serwera można to zrobić w następujący sposób:
[root@amanda ~]# cat /var/lib/dhcpd/dhcpd.leases lease 192.168.0.172 { starts 4 2016/12/29 15:45:23; ends 4 2016/12/29 15:55:23; tstp 4 2016/12/29 15:55:23; cltt 4 2016/12/29 15:45:23; binding state free; hardware ethernet 32:d8:1b:f4:69:82; uid "\0014\336\032\363\211\202"; }

Aby otrzymać lub wznowić przydział dla maszyny po kontrolą systemu Windows, można z wiersza poleceń Windows cmd, wydać następujące polecenie:
C:\Users\XNOTE>ipconfig /renew

Aby sprawdzić na wszystkich interfejsach sieciowych danego komputera, czy maszyna kliencka Windows otrzymała przydziały IP, a także odczytać inne informacje pozyskane wraz z przydziałami, można to zrobić w następujący sposób z wiersza poleceń Windows cmd:

C:\Users\XNOTE>ipconfig /all
Powodzenia! W przypadku pytań proszę o komentarze.

wtorek, 27 grudnia 2016

Aktualizacja serwera MariaDB z wersji 5.5 do wersji 10.1 w systemach Red Hat, Centos i Fedora

Aktualizacja pakietu MariaDB z wersji 5.5 do wersji 10.1 może wydawać się czynnością banalną, bo takową w rzeczywistości jest, lecz powikłania jej nieprawidłowego wykonania mogą spędzać sen z powiek niejednemu adminowi.
Ponieważ wewnętrzne struktury tabeli baz danych sporo się różnią pomiędzy tymi dwoma wersjami pakietów, kluczowe znaczenie w tej procedurze ma uruchomienie programu mysql_upgrade tuż po zainstalowaniu nowych wersji oprogramowania i uruchomieniu serwera MariaDB, ale tylko jeśli aktualizacja miała miejsce w systemach Red Hat, Fedora lub Centos, ponieważ pakiety oprogramowania w systemach Ubuntu i Debian wykonują tą czynność automatycznie i samodzielnie.
Przygotowałem ten krótki artykuł, ponieważ w ostatnim czasie zbyt wielu użytkowników Linuxa kontaktowało się ze mną w związku z problemami, które występowały po przejściu z wersji 5.5 do 10.1 pakietu MariaDB. Najbardziej zdesperowani byli Ci, którzy zatrudnieni są w dużych korporacjach, gdzie aktualizowano jednocześnie więcej serwerów. Niektorzy z nich wpadali w prawdziwy szał gdy serwer MariaDB nie uruchamiał się tuż po aktualizacji.
Najczęściej występujące problemy po aktualizacji z wersji 5.5 do wersji 10.1 to nie tylko brak możliwości uruchomienia serwera MariaDB, lecz także inne przykre błędy, uniemożliwiające normalne korzystanie z baz danych.
Przykładowe problemy występujące po błędnie wykonanej aktualizacji pakietu, na podstawie dziennika logów MariaDB:
[ERROR] mysqld: Can't lock aria control file '/var/lib/mysql/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds [ERROR] mysqld: Got error 'Could not get an exclusive lock; file is probably in use by another process' when trying to use aria control file '/var/lib/mysql/aria_log_control' [ERROR] Plugin 'Aria' init function returned error. [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed. [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! [ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. [ERROR] /usr/sbin/mysqld: unknown option '--log-slow-queries' [ERROR] Aborting

Aktualizacja MariaDB z wersji 5.5 do wersji 10.1 w systemach Red Hat, Fedora i Centos - zalecana procedura krok po kroku


1. Tworzymy plik /etc/yum.repos.d/MariaDB.repo, którego zawartość powinna wyglądać tak:
[mariadb] name = MariaDB
baseurl = http://yum1.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
2. Wykonujemy kopię zapasową wszystkich baz danych MariaDB. Przykładowo w następujący sposób:
[root@amanda /]# mysqldump -c --all-databases -p > backup_27122016.sql
3. Usuwamy wersje 5.5 pakietu oprogramowania MariaDB
[root@amanda /]# yum remove mariadb mariadb-server
4. Instalujemy nowe wersje oprogramowania
[root@amanda /]# yum install MariaDB-client MariaDB-server MariaDB-shared MariaDB-common
5. Uruchamiamy serwer
[root@amanda /]# systemctl start mariadb
6. Aktualizujemy strukturę istniejących tabeli MariaDB
[root@amanda /]# mysql_upgrade -p
Przykładowy wynik uruchomienia programu mysql_upgrade:


Zobacz film: aktualizacja MariaDB z 5.5 do 10.1 - jak to zrobić krok po kroku!


W przypadku prawidłowego wykonania procedury aktualizacyjnej pakiet MariaDB nie powinien sprawiać jakichkolwiek problemów. Powodzenia!