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.
You need to do : CREATE TABLE newtable LIKE oldtable; INSERT newtable SELECT * FROM oldtable; This creates copy of existing Mysql table with indexes
In Mysql shell execute: SHOW ENGINE INNODB STATUS \G Look for the Section – TRANSACTIONS Find transaction like:
Если у вас настроена репликация Mysql то иногда бинарные логи розрастаются до неймоверных обьемов. В таком случае эти логи можно скормить мастеру Mysql заодно освободив место на файловой системе Делается это так: master$ mysql -u root -pMypass -e “PURGE BINARY LOGS TO ‘mysql-bin.0066’;” Или так:
If you want update Mysql from 5.6 to 5.7 do this steps 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.deb After that you have apt-resources for installing Update resources apt-get update
При создании бекапа выскочина ошибка 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 = 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
В версии mysql 5.7 теперь нужно обязательно указывать время жизни пароля для root пользователя. Это может застать в расплох в самый неподходящий момент, особенно во время рестарта приложения. Чтобы этого избежать рекомендуэтся задать время его жизни такими способами. Установиль дефолтное значение через конфиг: Задаем 180дней [mysqld] default_password_lifetime=180 Безлимитные пароли: [mysqld] default_password_lifetime=0
С помощью утилит от 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.rpm… Читати далі »
Для InnoDB таблиц желательно использовать single-transaction mysqldump –single-transaction -u -p > backup.sql Для myISAM –lock-tables=false
После установки этого безобразия (1C-Bitrix) заметил, что медленно отрабатывает генерация страниц.. Копнув в лог заметил много таких вставок в БД TIME: 0.0178248882 SESSION: blkqvjd37heib431532gddfip5 CONN: Resource id #49 INSERT INTO b_stat_hit……. И каждая из них выполняется по 15-50мс Погуглив нашел решение.