PerconaDB

Iš Žinynas.
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Šiame puslapyje bus aprašomos MySQL v5.7 PerconaXTRA DB Cluster gyvenimiškos problemos, konfigūravimo ypatumai ir kiti scenarijai kurie pagalbėja administruojant tokio tipo klasterius.

Backup

xtrabackup --backup --target-dir=backup_dir/

Restore

xtrabackup --prepare --target-dir=backup_dir/
rsync -avrP backup_dir/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql

Klaidų sprendimas

Vienos DB backup/restore

backup

innobackupex --databases="duombaze" backupas/
innobackupex --apply-log --export backupas/2017-04-05_16-53-54/
tar cfpz backupas.tar.gz backupas/
scp -r backupas.tar.gz root@remote:

restore

systemctl stop mysql
tar xzf backupas.tar.gz
rsync -avrP backupas/2017-04-05_17-07-09/duombaze /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

MySQL Dump

mysqldump --single-transaction duombaze > duombaze.sql

Sudėjimas (serveryje įjungiame permissive režimą)

mysql > select @@pxc_strict_mode;  
mysql > SET pxc_strict_mode=PERMISSIVE;

Suimportavus atstatome:

mysql > SET GLOBAL pxc_strict_mode=ENFORCING; 

InnoDB: Cannot calculate statistics for table `clients`.`blah` because the .ibd file is missing.

ALTER TABLE clients IMPORT TABLESPACE; show warnings;

Crash recovery

https://www.percona.com/blog/2014/09/01/galera-replication-how-to-recover-a-pxc-cluster/
service mysql start --tc-heuristic-recover=0
service mysql start --tc-heuristic-recover=ROLLBACK
service mysql start --tc-heuristic-recover=COMMIT

Recovery po visu node'u išjungimo arba total crash

Prieš startuojant kurį nors node turim rasti replikavimo sekos "last sequence id", jis įrašomas į /var/lib/mysql/grstate.dat. Bet jeigu ten matome nulius ir sequence id -1. Įdedam į my.cnf wsrep_provider_options='pc.recovery=yes' (tik nepamirštam jo paskui išimti), tuomet papildomai reikia paleisti recovery mode:

# mysqld_safe --wsrep-recover
140821 15:57:15 mysqld_safe Logging to '/var/lib/mysql/percona3_error.log'.
140821 15:57:15 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
140821 15:57:15 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.6bUIqM' --pid-file='/var/lib/mysql/percona3-recover.pid'
140821 15:57:17 mysqld_safe WSREP: Recovered position 4b83bbe6-28bb-11e4-a885-4fc539d5eb6a:2
140821 15:57:19 mysqld_safe mysqld from pid file /var/lib/mysql/percona3.pid ended

Mums butinai reikia sužinoti kurio node sequence id yra paskutinesnis, tas ir bus kaip pagrindinis visiems likusiems node'ams replikuotis. Randame kuriame uuid yra normalūs, ne nuliai /var/lib/mysql/grastate.dat, jeigu yra seqno tai išvis pasaka dedame safe to bootstrap = 1 my.cnf pakeičiam wsrep_Address į gcom:// (po sėkmingo start reiks atkeisti atgal) ir startuojam pirmą node, kuris bus pagrindinis. Arba galime tiesiog parašyti (gcom:// analogas Debian sistemose):

/etc/init.d/mysql restart-bootstrap

Tuomet kai pagrindinis node pasikrauna, galime startuoti visus kitus su komanda:

service mysql start --wsrep_sst_donor=nodeC

Būtinai nurodome, prieš tai startavusio pagrindinio node pavadinimą. Jeigu bandymo replikuoti metu rodomas failed to connect sst user wrong password tada sutvarkome šia problemą, prisijungiame prie to mysql kuriame node jis pasikėlė tvarkingai ir parašome:

use mysql; DELETE FROM user where User ='sstuser'; flush privileges;
CREATE USER 'sstuser'@'%' IDENTIFIED BY 's3cret';
GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'%'; flush privileges;

Atitinkamai turi būti pakeistas ir my.cnf konfigūracinis failas. Toliau bandome įkrauti likusius node'us.

ibtmp1 data limitavimas

[mysqld]
innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G

Shared TMP

Situacija kai turime fizinį serverį su 4VPS kuriuose yra MySQL clusteris, bet pastoviai pritrūkstame vietos del neoptimizuotų užklausų. Kai MySQL selecto metu vyksta groupas ir orderis ir t.t. Galime naudoti vieną TMP folderį visiems VPS sharintą per NFS. Pagr. serveryje paruošiame TMP sharinimui, sukuriame /tempo direktoriją su 777 teisėmis. Įdiegiame NFS serverį:

apt-get install nfs-kernel-server 

Nustatome /etc/exports

/tempo       10.0.0.0/24(rw,nohide,insecure,no_subtree_check,async)

Perkrauname NFS servisą:

service nfs-kernel-server restart

Taip pat turėsime sukurti direktorijas /tempo/mysql-node1 ir t.t. su to vps mysql vartotojo id:group teisėmis, prieš tai pažiūrėję (id mysql). Pvz.:

chown 107:111 /tempo/mysql-node1

Kiekviename iš MySQL clusterio node'ų įdiegiame NFS client v4 palaikymą ir užmontuojame nutolusią failų sistemą, bei sutvarkome MySQL konfigūraciją:

apt-get install nfs-common 
mkdir /tempo

Į /etc/fstab įdedame:

10.0.0.1:/tempo   /tempo   nfs    auto  0  0

Primontuojame visas failų sistemas:

mount -a

Į /etc/mysql/my.cnf įrašome

[mysqld]
tmpdir = /tempo/mysql-node1

Išjungiame ir iš naujo paleidžiame mysql:

/etc/init.d/mysql stop
/etc/init.d/mysql start


Tvarkimasis su DeadLock'ais serverio lygmenyje

Galima naudoti (bet nepatartina):

 [mysqld]
wsrep_retry_autocommit=4

Monitoring

PerconaDB_Monitoring