Просмотрено
Метка: mysql

Mysql: wrong slave_master_info after upgrade to 5.7

Mysql: wrong slave_master_info after upgrade to 5.7

After upgrade mysql-server from 5.6 to 5.7.10 something strange going on with multimaster replication. When you add more then one channel replication tool not see second channel and server hangs on first channel. This happens because mysql_upgrade tool have a bug. This bug create columns in table slave_master_info in wrong order.

Mysql: purge Master logs

Mysql: purge Master logs

Если у вас настроена репликация Mysql то иногда бинарные логи розрастаются до неймоверных обьемов. В таком случае эти логи можно скормить мастеру Mysql заодно освободив место на файловой системе Делается это так: master$ mysql -u root -pMypass -e "PURGE BINARY LOGS TO ‘mysql-bin.0066’;"master$ mysql -u root -pMypass -e "PURGE BINARY LOGS TO ‘mysql-bin.0066’;" Или так:

Update MySQL to 5.7

Update MySQL to 5.7

If you want update Mysql from 5.6 to 5.7 do this steps https://dev.mysql.com/downloads/repo/apt/https://dev.mysql.com/downloads/repo/apt/ Download mysql-apt-config_0.6.0-1_all.deb Install apt-sources dpkg -i mysql-apt-config_0.6.0-1_all.debdpkg -i mysql-apt-config_0.6.0-1_all.deb After that you have apt-resources for installing Update resources apt-get updateapt-get update

Mysql: errno: 24 – Too many open files) (1018)

Mysql: errno: 24 – Too many open files) (1018)

При создании бекапа выскочина ошибка mysqldump: Couldn’t execute ‘SHOW TRIGGERS LIKE ‘logs”: Can’t read dir of ‘./mydatabase/’ (errno: 24 – Too many open files) (1018)mysqldump: Couldn’t execute ‘SHOW TRIGGERS LIKE ‘logs”: Can’t read dir of ‘./mydatabase/’ (errno: 24 – Too many open files) (1018) Хотя в limits.conf указано значение 30000 и в my.cnf open-files-limit = 20000open-files-limit = 20000 И процесс запущен с правильными параметрами /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –plugin-dir=/usr/lib64/mysql/plugin –log-error=/var/lib/mysql/error.log –open-files-limit=20000 –pid-file=/var/run/mysql.run –port=3306/usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –plugin-dir=/usr/lib64/mysql/plugin –log-error=/var/lib/mysql/error.log –open-files-limit=20000 –pid-file=/var/run/mysql.run –port=3306

Mysql 5.7: ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

Mysql 5.7: ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

В версии mysql 5.7 теперь нужно обязательно указывать время жизни пароля для root пользователя. Это может застать в расплох в самый неподходящий момент, особенно во время рестарта приложения. Чтобы этого избежать рекомендуэтся задать время его жизни такими способами. Установиль дефолтное значение через конфиг: Задаем 180дней [mysqld] default_password_lifetime=180 [mysqld] default_password_lifetime=180 Безлимитные пароли: [mysqld] default_password_lifetime=0 [mysqld] default_password_lifetime=0

Percona xtrabackup или переносим базу на другой сервер

Percona xtrabackup или переносим базу на другой сервер

С помощью утилит от percona можно поднять копию большой базы на другом сервере намного быстрее, чем штатными методами mysql dump/restore Сначала установим Percona XtraBackup и те зависимости, которые нужны. Установку будем проводить на Centos 6 wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.2.12/binary/redhat/6/x86_64/Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar tar xvf Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar yum install -y perl-DBD-MySQL yum install -y perl-Time-HiRes yum install -y rsync rpm -ivh percona-xtrabackup-2.2.12-1.el6.x86_64.rpmwget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.2.12/binary/redhat/6/x86_64/Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar tar xvf Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar yum install -y perl-DBD-MySQL yum install -y perl-Time-HiRes yum install -y rsync rpm -ivh percona-xtrabackup-2.2.12-1.el6.x86_64.rpm Теперь сделаем бекап и закинем его…

Читать далее Читать далее

Mysqldump: без блокировки InnoDB таблиц

Mysqldump: без блокировки InnoDB таблиц

Для InnoDB таблиц желательно использовать single-transaction mysqldump –single-transaction -u <user> -p <database> <table1> <table2> > backup.sqlmysqldump –single-transaction -u <user> -p <database> <table1> <table2> > backup.sql Для myISAM –lock-tables=false–lock-tables=false