31

mysql -uUSER -pPWD
STOP SLAVE;
QUIT;

# change to jtel user
su jtel
# Find out which software release is installed
cd /srv/jtel/shared/JTELCarrierPortal
git status

# If /srv/jtel/.. does not exist on the load balancerSTORE, attempt this
cd /home/jtel/shared/JTELCarrierPortal
git status

# Expected output
release-stable/3.XX

# Create backup directory
JT_DATE_TIME=$(date +%F)

# Create backup directory SLAVE MySQL Dump - Until jtel Portal release 3.12
mkdir /srv/jtel/shared/backup/DATUM
${JT_DATE_TIME}
# If /srv/jtel/.. does not exist on the load balancer, attempt this 
JT_DATE_TIME=$(date +%F)
mkdir /srvhome/jtel/shared/backup/DATUM

${JT_DATE_TIME}  

mysql --version

# Change to backup directory
cd /srv/jtel/shared/backup/DATUM
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<Alias or IP-Adress of master database> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > acd-dbm_<yyyymmdd>.sql

# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump 
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql

MySQL Dump - From Release 3.32

# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump 
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELStats2 JTELLog JTELCustomer --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql

MySQL Dump - From MySQL 8.0.27

# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump 
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --source-data --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > 

MySQL Dump - From MySQL 8.0.27

To Check for MySQL Version, log in to the master database server and execute the following command

mysql --version

# Change to backup directory
cd /srv/jtel/shared/backup/DATUM
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<Alias or IP-Adress of master database> --single-transaction --source-data --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > acd-dbm_<yyyymmdd>.sql

Brief Explanation of the mysqldump command

• <Name LogFile> and <Position LogFile> are saved through --master-data or --source-data in the dump

• use only the JTEL databases '--databases'

• delete all databases before import  '--add-drop-database'

• delete all tables of the databases before import '--add-drop-table'

• Implement all routines and procedures in the dump '--events --routines'

• Additionally the parameter --default_character_set utf8 can be used

Phase 2 - Import Dump on Slave Database

Import Dump - tmux

# switch to root user
su root
# start tmux sub-session
tmux new
# change to the directory where the dump file is located
cd /srv/jtel/shared/backup/${JT_DATE/
# copy the name
ls -als
# log in to mysql and import the dump
mysql -uroot -p<password>
source <acd-_TIME}/acd-dbm_<yyyymmdd>.sql>

Import Dump - No tmux

# switch to root user
su root
# change to the directory where the dump file is located
cd /srv/jtel/shared/backup/DATE/
# copy the name
ls -als
# log in to mysql and import the dump
mysql -uroot -p<password>
source <acd-dbm_<yyyymmdd>.sql>

Start Slave - tmux

# If not attached to the sub-session anymore
tmux attach
# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G

Start Slave - No tmux

# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G

Slave Disk Full

There are several reasons why the slave disk can become full. Following is a summary of the different cases and further below is a detailed explanation:

ibdata files on the slave "very large"

Still no disk space > 20% free

tmp Directory Is Full

Introduction

Every time a query creates a tmp table, it is written to the temp directory, usually /tmp. This happens when the maximum size exceeds the maximum "in memory" table size. This is defined with the variables tmp_table_size aswell as max_heap_table_size .

The tables in /tmp are kept until the respective DB connection is closed or a DROP TEMPORARY TABLE is called. If the /tmp directory is full, it is likely that a DROP TEMPORARY TABLE is missing somewhere. This can also happen through customer queries to the DB.

The installation of tmpwatch creates help in a permanent way

Hints:

• On CentOS 6 the /tmp directory is then by default freed from files that have not been accessed for > 10 days
  
  • Circumstantially this may not be sufficient
• On CentOS 7 the /tmp directory is then freed by default from files that have not been accessed for> 1 day

Procedure

1. Space must first be made available. Just mercilessly delete everything from /tmp.
2. If this provides enough space, then restart the mysql service first: service mysql restart
3. If there is enough space (at least about 20%), then proceed with replication as described above.

Lots of "relay logs" available

Introduction

MySQL first writes the relay logs from the master to a file. Once replication is interrupted, but the slave relay process continues to operate, the disk is filled by relay logs. 

This step should be done in any case, especially before the next one (ibdata too large) to make room.

Procedure

The files for the database are usually located in /var/lib/mysql

If not, the location can be found in /etc/my.cnf The corresponding entry is datadir=(pfad)

Delete all relay logs:

Restart MySQL service

service mysqld restart

If enough space is available (at least 20%) then proceed with the slave recovery as described above.

ibdata files on the slave "very large"

Introduction

The files for the database are usually located in /var/lib/mysql

Procedure

If no less than 100% disk can be achieved by the steps above:

Unsubscribe the MySQL service from the autostart:

systemctl disable mysqld

Restart the computer with :

systemctl reboot now

Only works if less than 100% disk is reached (possibly after reboot above) then

Log on to the mysql server:

mysql -u root -p

Drop all JTEL databases:

SET FOREIGN_KEY_CHECKS=0;
DROP DATABASE JTELLog;
DROP DATABASE JTELStats;
DROP DATABASE JTELWeb;
SET FOREIGN_KEY_CHECKS=1;

Press CTRL+C to return to the command line, and then

service mysqld stop
rm /var/lib/mysql/ibdata*
rm /var/lib/mysql/ib_log_*

Start MySql Server, and enable it again if necessary:

service mysqld start
service mysqld enable

Check disk space, and proceed with Slave Restore as described above.

Still no disk space > 20% free

Introduction

The slave disk space is still full, more than 80% of the space on the drive is used by normal operation

Solution

In this case the slave is simply too small. The hard disk must be expanded (as with extending the STORE role, apply only to the logical volume where the MySQL database data resides). Then perform the steps again, if the disk is too small, then restore the slave as described above.

Or the slave is completely rebuilt with a larger plate.

sql

Brief Explanation of the mysqldump command

• <Name LogFile> and <Position LogFile> are saved through --master-data or --source-data in the dump

• use only the JTEL databases '--databases'

• delete all databases before import  '--add-drop-database'

• delete all tables of the databases before import '--add-drop-table'

• Implement all routines and procedures in the dump '--events --routines'

• Additionally the parameter --default_character_set utf8 can be used

Phase 2 - Import Dump on Slave Database

Import Dump - tmux

# switch to root user
sudo -s
# start tmux sub-session
tmux new
# change to the directory where the dump file is located
JT_DATE_TIME=$(date +%F)
cd /srv/jtel/shared/backup/${JT_DATE_TIME}/
# copy the dump-filename
ls -als
# log in to mysql and import the dump
mysql -hacd-dbs -uroot -p<password>
source <acd-dbm_<yyyymmdd>.sql>;

Import Dump - No tmux

# switch to root user 
sudo -s
# change to the directory where the dump file is located
JT_DATE_TIME=$(date +%F)
cd /srv/jtel/shared/backup/${JT_DATE_TIME}/
# copy the dump-filename
ls -als
# log in to mysql and import the dump
mysql -hacd-dbs -uroot -p<password>
source <acd-dbm_<yyyymmdd>.sql>;

Check status

You can check the progress by executing the following command on acd-dbs

watch 'mysql -uroot -p<password> -e "SHOW PROCESSLIST;"'

Start Slave - tmux

# If not attached to the sub-session anymore
tmux attach
# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G

Start Slave - No tmux

# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G

Slave Disk Full

There are several reasons why the slave disk can become full. Following is a summary of the different cases and further below is a detailed explanation:

tmp Directory Is Full

Introduction

Every time a query creates a tmp table, it is written to the temp directory, usually /tmp. This happens when the maximum size exceeds the maximum "in memory" table size. This is defined with the variables tmp_table_size aswell as max_heap_table_size .

The tables in /tmp are kept until the respective DB connection is closed or a DROP TEMPORARY TABLE is called. If the /tmp directory is full, it is likely that a DROP TEMPORARY TABLE is missing somewhere. This can also happen through customer queries to the DB.

The installation of tmpwatch creates help in a permanent way

Hints:

• On CentOS 6 the /tmp directory is then by default freed from files that have not been accessed for > 10 days
  
  • Circumstantially this may not be sufficient
• On CentOS 7 the /tmp directory is then freed by default from files that have not been accessed for> 1 day

Procedure

1. Space must first be made available. Just mercilessly delete everything from /tmp.
2. If this provides enough space, then restart the mysql service first: service mysql restart
3. If there is enough space (at least about 20%), then proceed with replication as described above.

Lots of "relay logs" available

Introduction

MySQL first writes the relay logs from the master to a file. Once replication is interrupted, but the slave relay process continues to operate, the disk is filled by relay logs. 

This step should be done in any case, especially before the next one (ibdata too large) to make room.

Procedure

The files for the database are usually located in /var/lib/mysql

If not, the location can be found in /etc/my.cnf The corresponding entry is datadir=(pfad)

Delete all relay logs:

Reconstruire la BD-esclave et Réplication

Comme la commande mysqldump verrouille les tables, il n'est pas nécessaire qu'il n'y ait pas de trafic sur la base de données principale. Avec --master-data, la commande mysqldump enregistre la position correcte pour l'insertion de la réplication sur le serveur esclave. 

Si le disque dur de l'esclave est plein, veuillez vous référer aux instructions sur cette page ci-dessous - "Disque d'esclave complet".

Connectez-vous à MySQL avec les identifiants USER et PWD, puis arrêtez l'esclave et quittez MySQL à nouveau. Utilisez pour cela les commandes suivantes :

Écrire un dump MySQL. Exécutez maintenant les étapes suivantes sur le serveur maître. Créez un répertoire de sauvegarde et changez pour le même. Le dumb MySQL est maintenant exécuté avec la commande suivante

• mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql

  A partir de la version 3.12, veuillez utiliser la commande suivante :

• mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql


Voici une brève explication à ce sujet :

Nous retournons à la serveur esclave et maintenant importer mysqldump.

CHANGE MASTER TO MASTER_HOST='<name or ip of master servers>',MASTER_USER='repl',MASTER_PASSWORD='<passwort>',MASTER_LOG_FILE='<Name LogFile>', MASTER_LOG_POS=<Position LogFile>;
Ici, tous les paramètres doivent être remplacés par ceux de l'étape 5.

Maintenant, nous vérifions le statut de l'esclave (plusieurs fois) avec la commande 

• Slave_IO_Running: Oui

• Slave_SQL_Running: Oui

Disque d'esclave complet

Il y a plusieurs raisons pour lesquelles le disque esclave peut devenir plein.

le répertoire tmp est complet

Informations générales

Chaque fois qu'une requête crée une table tmp, elle est écrite dans le répertoire temporaire, généralement/tmp. Cela se produit lorsque la taille maximale dépasse la taille maximale de la table "en mémoire". Ceci est défini avec les variables tmp_table_size aussi bien que max_heap_table_size .

See also https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html pour plus d'informations. 

Les tables dans / tmp sont conservées jusqu'à ce que la connexion DB respective soit fermée ou qu'une DROP TEMPORARY TABLE soit appelée. Si le répertoire / tmp est plein, il est probable qu'un DROP TEMPORARY TABLE manque quelque part. Cela peut également se produire via des requêtes client adressées à la base de données.

L'installation de tmpwatch crée de l'aide de façon permanente

Indices:

• Sous CentOS 6, le répertoire /tmp est alors par défaut libéré des fichiers qui n'ont pas été consultés pour > 10 jours
  
  • Cela peut ne pas être suffisant
• Sous CentOS 7, le répertoire /tmp est alors libéré par défaut des fichiers qui n'ont pas été consultés depuis > 1 jour

Procédure

1. Un espace doit d'abord être mis à disposition. Il suffit de tout supprimer impitoyablement dans /tmp.
2. Si cela permet de disposer de suffisamment d'espace, il faut d'abord redémarrer le service mysql : service mysql restart
3. S'il y a suffisamment d'espace (au moins environ 20 %), il faut alors procéder à la réplication comme décrit ci-dessus.

Beaucoup de "journaux de relais" disponibles

MySQL écrit d'abord les journaux de relais du maître dans un fichier. Une fois que la réplication est interrompue, mais que le processus de relais esclave continue à fonctionner, le disque est rempli par les journaux de relais. 

Cette étape doit être effectuée dans tous les cas, surtout avant la prochaine (ibdata trop grande) pour faire de la place.

Procédure

Les fichiers de la base de données se trouvent généralement dans /var/lib/mysql

Si ce n'est pas le cas, le lieu peut être trouvé dans /etc/my.cnf L'entrée correspondante est datadir=(pfad)

Effacer tous les journaux de relais :

Restart MySQL service

translations-ignore

service mysqld restart

Si l'espace disponible est suffisant (au moins 20 %), il faut alors procéder à la récupération d'esclave comme décrit ci-dessus.

If enough space is available (at least 20%) then proceed with the slave recovery as described above.

ibdata files on the slave "very large"

Introduction

The files for the database are usually located in

fichiers ibdata sur l'esclave "très grand"

Les fichiers de la base de données se trouvent généralement dans /var/lib/mysql

Procédure

Désinscrire le service MySQL au démarrage automatique :

Redémarrez l'ordinateur avec :

Ne fonctionne que si le disque est inférieur à 100% (éventuellement après le redémarrage ci-dessus) alors

Connectez-vous au serveur mysql :

Supprimer toutes les bases de données JTEL :

Procedure

If no less than 100% disk can be achieved by the steps above:

Unsubscribe the MySQL service from the autostart:

systemctl disable mysqld

Restart the computer with :

systemctl reboot now

Only works if less than 100% disk is reached (possibly after reboot above) then

Log on to the mysql server:

mysql -u root -p

Drop all JTEL databases:

SET 

FOREIGN_KEY_CHECKS=0;

DROP DATABASE JTELLog;

DROP DATABASE JTELStats;

DROP DATABASE JTELWeb;

SET FOREIGN_KEY_CHECKS=1;

Press CTRL+C

to return to the command line, and then

service mysqld stop
rm /var/lib/mysql/ibdata*

rm /var/lib/mysql/ib_log_*

Start MySql Server,

Vérifiez l'espace disque, et procédez à la restauration des esclaves comme décrit ci-dessus.

Toujours pas d'espace disque > 20% gratuit

Dans ce cas, l'esclave est tout simplement trop petit. Le disque dur doit être étendu (comme pour l'extension du rôle STORE, ne s'applique qu'au volume logique où résident les données de la base de données MySQL). Effectuez ensuite à nouveau les étapes, si le disque est trop petit, restaurez l'esclave comme décrit ci-dessus.

and enable it again if necessary:

service mysqld start
service mysqld enable

Check disk space, and proceed with Slave Restore as described above.

Still no disk space > 20% free

Introduction

The slave disk space is still full, more than 80% of the space on the drive is used by normal operation

Solution

In this case the slave is simply too small. The hard disk must be expanded (as with extending the STORE role, apply only to the logical volume where the MySQL database data resides). Then perform the steps again, if the disk is too small, then restore the slave as described above.

Or the slave is completely rebuilt with a larger plate.