Master Server (Primary)
Folgende Schritte sind erforderlich, um einen DATA Server als Master zu konfigurieren.
Als erstes muss ein entsprechendes Konfigurationsmodul erstellt werden. Dies erfolgt mit folgendem Befehl:
cat <<EOFF > /etc/my.cnf.d/jtel-master.cnf # Custom MySQL settings for a specific SQL master server # # WARNING: This file is specific to the master server [mysqld] # # Replication Options # # Specific options for MASTER role # server_id = 1 binlog_format = ROW expire_logs_days = 3 max_binlog_size = 100M log_bin = binlog EOFF
ACHTUNG
Der Wert server_id
taucht sowohl in den Konfigurationsmodulen für Master-Server als auch in den Konfigurationsmodulen für Slave-Server auf. Hierbei ist strikt darauf zu achten, dass dieser Wert eindeutig ist. In einem Verbund dürfen keine DATA-Server die gleiche server_id
haben.
Als nächstes wird ein Benutzer angelegt, mit dem sich die Slave-Server mit dem Master-Server verbinden können:
mysql -u root -pfireball -v -e"CREATE USER 'repl'@'%' IDENTIFIED BY 'fireball'" mysql -u root -pfireball -v -e"GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'" mysql -u root -pfireball -v -e"FLUSH PRIVILEGES"
Im Anschluss muss der MySQL-Server neu gestartet werden, damit alle Einstellungen übernommen werden:
service mysqld restart
Installation des Hazelcast Platform UDP Listeners (ab Version 3.06)
Ab Version 3.06 der jtel-Software muss auf dem Primären DATA-Server weitere Software installiert werden. Da der UDP Listener Prozess die Java-Laufzeitumgebung erfordert, muss diese vorab mit folgendem Befehl installiert werden:
yum -y install http://cdn.jtel.de/downloads/java/jdk-7u79-linux-x64.rpm
Im Anschluss wird der UDP Listener mit folgenden Befehlen installiert:
cp -a /home/jtel/shared/JTELCarrierPortal/Utils/Install/PlatformUDPlistener/ /home/jtel/ cp -a /home/jtel/PlatformUDPlistener/init.d/jtel-listener /etc/init.d
ACHTUNG
Wenn die Repositories auf einer Windows Maschine liegen und der PlattformUDPlistener vor dort auf dem DATA in /etc/init.d kopiert wird, dann muss folgender Befehl noch ausgeführt werden:
sed -i -e 's/\r//g' /etc/init.d/jtel-listener
Da die Datei von einer Windows Maschine kopiert wird, ist die Datei unter Unix nicht in Ordnung.
Als nächstes muss die Konfigurationsdatei des UDP Listeners der Umgebung angepasst werden. Hierfür muss die Datei /home/jtel/PlatformUDPlistener/conf/hazelcast.xml
entsprechend angepasst werden. Hierbei sind insbesondere folgende zwei Abschnitte anzupassen:
<group> <name>jtel-cluster-NAME</name> <password>jtel-cluster-pass</password> </group>
Da nicht hundertprozentig auszuschließen ist, dass sich im Netz weitere auf Hazelcast basierende Applikationen befinden können (wie z.B. weitere jtel-Systeme in größeren Cloud-Umgebungen, ist es wichtig für das entsprechende jtel-System den Cluster-Namen und das Cluster-Passwort zu individualisieren.
Ein weiterer wichtiger Abschnitt betrifft die Zusammensetzung des Clusters. Im Auslieferungszustand ist die Konfigurationsdatei so ausgelegt, dass die Cluster-Members sich mittels Multicast finden und kommunizieren. Diese Methode sollte im Wirkbetrieb nicht verwendet werden, da sie zusätzlichen überflüssigen Netzwerkverkehr erzeugt und auch Auswirkungen auf andere Applikationen haben kann. Des weiteren wäre dafür eine Firewall-Konfiguration erforderlich, die hier nicht weiter erörtert wird. Aus diesem Grunde ist diese Kommunikationsform abzuschalten (<multicast enabled="false" />
) und hingegen die Liste der Kommunikationspartner einzutragen. Dabei ist darauf zu achten, dass der entsprechende Abschnitt, der im Auslieferungszustand auskommentiert ist, aktiviert werden muss. Die Liste der Kommunikationspartner setzt sich folgendermaßen zusammen:
- Der primäre DATA-Server
- Jeder TEL-Server
- Jeder WEB-Server
Im spezifischen Fall des hier vorgestellten Installationsszenario, würden die Anpassungen folgendermaßen aussehen:
<network> <join> <!-- DO NOT USE MULTICAST IN PRODUCTION ENVIRONMENTS --> <multicast enabled="false" /> <!-- USE THIS SECTION INSTEAD AND ADAPT THE LIST OF MEMBERS --> <tcp-ip enabled="true"> <member>192.168.1.21</member> <member>192.168.1.31</member> <member>192.168.1.32</member> <member>192.168.1.40</member> </tcp-ip> </join> </network>
Da diese Konfigurationsdatei auf allen oben aufgelisteten Servern existieren muss und exakt gleich sein muss, empfiehlt es sich die nun angepasste Datei kurzfristig ins freigegebene Verzeichnis zu kopieren, so dass sie bei der Installation der folgenden Rollen direkt von dort bezogen werden kann:
cp /home/jtel/PlatformUDPlistener/conf/hazelcast.xml /home/jtel/shared
Der UDP Listener Dienst wird mit folgendem Befehl in die Liste der automatisch startenden Dienste aufgenommen:
cd /etc/init.d chkconfig jtel-listener on
Als nächstes müssen in der Firewall die Port-Freigaben für den UDP Listener Dienst eingetragen und persistent gespeichert werden:
firewall-cmd --zone=public --add-port=5701-5801/tcp --permanent firewall-cmd --reload
Nun muss der UDP Listener manuell gestartet werden:
service jtel-listener start
Um die Aktualisierung des USP Listeners zu vereinfachen, wird nun noch ein entsprechendes Skript erstellt:
cat <<EOFF > /usr/local/bin/updatepl.sh #!/bin/bash service jtel-listener stop cp /home/jtel/shared/JTELCarrierPortal/Utils/Install/PlatformUDPlistener/bin/platform-UDP-listener-1.0-jar-with-dependencies.jar /home/jtel/PlatformUDPlistener/bin chown jtel:jtel /home/jtel/PlatformUDPlistener/bin/* service jtel-listener start EOFF chmod +x /usr/local/bin/updatepl.sh
MySQL-Backup anlegen (Nur einer der Master)
CONFIG_mysql_dump_username='root' CONFIG_mysql_dump_password='fireball' CONFIG_backup_dir='/home/jtel/backup/sql' CONFIG_mysql_dump_host='localhost' URI="http://downloads.sourceforge.net/project/automysqlbackup/AutoMySQLBackup/AutoMySQLBackup%20VER%203.0/automysqlbackup-v3.0_rc6.tar.gz" cd /home/jtel mkdir -p /home/jtel/automysqlbackup mkdir -p ${CONFIG_backup_dir} cd /home/jtel/automysqlbackup curl -O -L ${URI} tar xfvz ${URI##*/} cp automysqlbackup.conf automysqlbackup.conf.orig cp automysqlbackup automysqlbackup.orig # remove parameter '--password' to fall back to .my.cnf sed -i -e 's/--password="${CONFIG_mysql_dump_password}" //' automysqlbackup cat << EOF > /home/jtel/.my.cnf [client] user = ${CONFIG_mysql_dump_username} password = ${CONFIG_mysql_dump_password} host = ${CONFIG_mysql_dump_host} EOF cat /home/jtel/.my.cnf cat << EOF > automysqlbackup.conf CONFIG_mysql_dump_username="${CONFIG_mysql_dump_username}" CONFIG_mysql_dump_password="${CONFIG_mysql_dump_password}" CONFIG_mysql_dump_host="${CONFIG_mysql_dump_host}" CONFIG_backup_dir="${CONFIG_backup_dir}" # Include CREATE DATABASE in backup? CONFIG_mysql_dump_create_database='yes' # Separate backup directory and file for each DB? (yes or no) CONFIG_mysql_dump_use_separate_dirs='no' # List of databases for Daily/Weekly Backup e.g. ( 'DB1' 'DB2' 'DB3' ... ) # set to (), i.e. empty, if you want to backup all databases #CONFIG_db_names=() # List of databases for Monthly Backups. # set to (), i.e. empty, if you want to backup all databases #CONFIG_db_month_names=() # List of DBNAMES to EXLUCDE if DBNAMES is empty, i.e. (). CONFIG_db_exclude=( 'information_schema' 'performance_schema' ) # Rotation Settings # Which day do you want monthly backups? (01 to 31) # If the chosen day is greater than the last day of the month, it will be done # on the last day of the month. # Set to 0 to disable monthly backups. #CONFIG_do_monthly="01" # Which day do you want weekly backups? (1 to 7 where 1 is Monday) # Set to 0 to disable weekly backups. #CONFIG_do_weekly="5" # Set rotation of daily backups. VALUE*24hours # If you want to keep only today's backups, you could choose 1, i.e. everything older than 24hours will be removed. #CONFIG_rotation_daily=6 # Set rotation for weekly backups. VALUE*24hours #CONFIG_rotation_weekly=35 # Set rotation for monthly backups. VALUE*24hours #CONFIG_rotation_monthly=150 EOF /home/jtel/automysqlbackup/automysqlbackup /home/jtel/automysqlbackup/automysqlbackup.conf cat << 'EOF' > automysqlbackup.cron #!/bin/bash su - jtel -c '/home/jtel/automysqlbackup/automysqlbackup /home/jtel/automysqlbackup/automysqlbackup.conf' EOF chmod 750 automysqlbackup.cron sudo ln -s /home/jtel/automysqlbackup/automysqlbackup.cron /etc/cron.daily
Auf dem Master Server wird das MySQL-Backup angelegt. Der Server führt täglich das Backup aus und löscht alle Dateien, die älter als 7 Tage sind.
Slave Server
Folgende Schritte sind erforderlich, um einen DATA-Server als Slave zu konfigurieren. Es handelt sich hierbei um eine unverschlüsselte Replikation. Eine verschlüsselte Replikation kann gemäß https://www.thomas-krenn.com/de/wiki/MySQL_Verbindungen_mit_SSL_verschl%C3%BCsseln umgesetzt werden.
Als erstes muss ein entsprechendes Konfigurationsmodul erstellt werden. Dies erfolgt mit folgendem Befehl:
cat <<EOFF > /etc/my.cnf.d/jtel-slave.cnf # Custom MySQL settings for a specific SQL slave server # # WARNING: This file is specific to the slave server [mysqld] # Specific options for SLAVE role # server_id = 2 EOFF
ACHTUNG
Der Wert server_id
taucht sowohl in den Konfigurationsmodulen für Master-Server als auch in den Konfigurationsmodulen für Slave-Server auf. Hierbei ist strikt darauf zu achten, dass dieser Wert eindeutig ist. In einem Verbund dürfen keine DATA-Server die gleiche server_id
haben.
Im Anschluss muss der MySQL-Server neu gestartet werden, damit alle Einstellungen übernommen werden:
service mysqld restart
Replikation des Slave Servers bei Erstinstallation einrichten und starten
Als erstes sollte geprüft werden, dass die Kommunikation zwischen Slave und Master Server einwandfrei funktioniert. Dies kann getestet werden, in dem versucht wird sich mittels des MySQL-Clients mit dem Replikationsbenutzer an den Master Server anzumelden:
[root@acd-dbs ~]# mysql -h acd-dbm -u repl -pfireball -v -e "SHOW DATABASES" Warning: Using a password on the command line interface can be insecure. -------------- SHOW DATABASES -------------- +--------------------+ | Database | +--------------------+ | information_schema | +--------------------+ [root@acd-dbs ~]#
Sollte dies nicht funktionieren, muss die Ursache geprüft und beseitigt werden. Mögliche Ursachen:
- Master Server läuft nicht
- Firewallkonfiguration auf dem Master Server
- Replikationsbenutzer nicht angelegt oder fehlerhaft
Als nächstes muss der Aktuelle Stand des Binlogs auf dem Master-Server abgefragt werden:
[root@acd-dbs ~]# mysql -h acd-dbm -u root -pfireball -v -e "SHOW MASTER STATUS" Warning: Using a password on the command line interface can be insecure. -------------- SHOW MASTER STATUS -------------- +---------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+-------------------+ | binlog.000001 | 120 | | | | +---------------+----------+--------------+------------------+-------------------+ [root@acd-dbs ~]#
Diese Informationen werden nun benötigt, um auf dem Slave-Server die Replikation zu konfigurieren. Um dies einzuleiten, ist es erforderlich den MySQL-Client mit einer Verbindung zum Slave-Server zu starten:
mysql -u root -pfireball
Im MySQL-Client werden nun folgende Befehle eingeben die entsprechend der vorher ermittelten Positionsdaten anzupassen sind:
CHANGE MASTER TO MASTER_HOST='acd-dbm',MASTER_USER='repl',MASTER_PASSWORD='fireball',MASTER_LOG_FILE='binlog.000001',MASTER_LOG_POS=120; START SLAVE; SHOW SLAVE STATUS\G
Der letzte dieser drei Befehle gibt Aufschluß über den Status der Replikation. Die Ausgabe umfasst mehrere Zeilen. Im Erfolgsfall sollte unbedingt folgende Zeile zu sehen sein:
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
ACHTUNG
Die vorhergehende Anleitung ist nur gültig, falls der Master-Server "frisch" ist und noch keine Datenbanken enthält. Wird hingegen ein Slave-Server einem bereits bestehenden jtel-System hinzugefügt, muss hier anders vorgegangen werden. Der nachfolgende Abschnitt beschreibt die dafür benötigte Prozedur.
Replikation des Slave Servers einrichten und Starten bei bereits bestehendem jtel-System
Soll ein Slave-Server einem bereits bestehenden und laufenden jtel-System hinzugefügt werden, so ist die Vorgehensweise für die Konfiguration anderes als bei einer Erstinstallation. Auch hier muss vorher geprüft werden, ob die Kommunikation zum Master Server einwandfrei funktioniert. Die Vorgehensweise hierfür ist im vorigen Abschnitt beschrieben.
Als nächstes muss vom Master-Server eine Kopie der Daten inklusive der Information welchem Binlog-Stand diese Kopie entspricht erstellt werden. DIes erfolgt mittels folgendem Befehl:
mysqldump -h acd-dbm -u root -pfireball --master-data=2 --add-drop-database --add-drop-table --events --routines --databases JTELWeb JTELStats JTELLog > dump.sql
Diese Prozedur kann je nach Größe der bestehenden Datenbank recht lange dauern. Als nächstes muss die Information über den aktuellen Stand des Binlogs auf dem Master-Server aus dem gesicherten Snapshot ermittelt werden. Dies erfolgt praktischerweise über folgendem Befehl und könnte so aussehen:
[root@acd-dbs ~]# head -n 1000 dump.sql | grep "CHANGE MASTER" -- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000003', MASTER_LOG_POS=8624588; [root@acd-dbs ~]#
Als nächstes muss der Snapshot nun in das frisch installierte Slave-System importiert werden. Dies erfolgt über folgende Befehl:
mysql -u root -pfireball -v -e "source dump.sql"
Auch diese Prozedur kann je nach Größe der bestehenden Datenbank recht lange dauern. War der Import des Snapshots erfolgreich, kann die Replikation nun mit Hilfe der vorher ermittelten Positionsdaten konfiguriert und gestartet werden. Um dies einzuleiten, ist es erforderlich den MySQL-Client mit einer Verbindung zum Slave-Server zu starten:
mysql -u root -pfireball
Im MySQL-Client werden nun folgende Befehle eingeben die entsprechend der vorher ermittelten Positionsdaten anzupassen sind:
CHANGE MASTER TO MASTER_HOST='acd-dbm',MASTER_USER='repl',MASTER_PASSWORD='fireball',MASTER_LOG_FILE='binlog.000003',MASTER_LOG_POS=8624588; START SLAVE; SHOW SLAVE STATUS\G
Der letzte dieser drei Befehle gibt Aufschluß über den Status der Replikation. Die Ausgabe umfasst mehrere Zeilen. Im Erfolgsfall sollte folgende Zeile zu sehen sein:
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Ist zwischen dem Erstellen des Snapshots und dem aktivieren der Replikation einige Zeit vergangen, kann es unter Umständen ein wenig dauern, bis dass der Slave Server die inzwischen aufgelaufenen Änderungen nachgeholt hat. In dieser Phase wird man unter Slave_SQL_Running_State
verschiedene Meldungen über die gerade ausgeführte Operation sehen. Erst wenn alle Änderungen nachgeholt wurden und zur Zeit keine weiteren Operationen anfallen, ist die oben aufgeführte Meldung zu sehen. Der Befehl SHOW SLAVE STATUS\G
kann beliebig oft ausgeführt werden, um den Fortschritt zu verfolgen.
Ersteinrichtung der Systemdaten
Die folgenden Operationen erfolgen nicht mehr im Kontext des Benutzers root
sondern müssen im Kontext des Benutzers jtel
ausgeführt werden. Dafür kann man sich entweder in einer separaten SSH Sitzung als Benutzer jtel
anmelden oder, wenn man bereits als Benutzer root
angemeldet ist, in den Kontext des Benutzers jtel
wechseln. Dies erfolgt durch folgenden Befehl:
su jtel cd
Nach Eingabe dieser Befehle erkennt man den Benutzerwechsel am Systemprompt, welches nun [jtel@acd-db1 ~]$
lautet (Das Systemprompt setzt sich zusammen ausbenutzername@hostname aktuelles Verzeichnis
).
ACHTUNG
Wenn diese Operation von einer anderen Maschine ausgeführt werden sollte, dann ist unbedingt darauf zu achten, daß als Zielserver der primäre DATA-Server angegeben wird. Im Nachfolgenden Beispiel wird davon ausgegangen, dass die Operation auf dem primären DATA-Server ausgeführt wird, der Zielserver ist also localhost
.
Die Ersteinrichtung der Datenbank erfolgt über folgende Befehle:
cd ~/shared/JTELCarrierPortal/DB/mySQL/init mysql -h localhost -u root -pfireball -vvv -f -n -q -e"source Init.sql" cd ~/shared/JTELCarrierPortal/DB/mySQL ./update_all.sh root:fireball@localhost cd ~/shared/JTEL/DB ./update_all.sh root:fireball@localhost
Im Falle dass für den Kunden noch spezifische Anpassungen oder Erweiterungen programmiert wurden die auch spezifische Anpassungen der Datenbank enthalten, muss zusätzlich das kundenspezifische Datenbank-Skript ausgeführt werden. Dies erfolgt exemplarisch durch einen Befehl der folgendermaßen aufgebaut ist:
cd ~/shared/acme/DB ./update_all.sh root:fireball@localhost
All diese Skripte geben Feedback über ihren Fortschritt und Erfolg. Sollte es bei der Ausführung eines dieser Skripte eine Fehlermeldung geben, so ist sorgfältig zu prüfen, ob die Übergebenen Parameter korrekt sind (z.B. Datenbankpasswort, Hostname). Eine erfolgreiche Ausführung sieht folgendermaßen aus:
[jtel@acd-db1 ~]$ cd ~/shared/JTELCarrierPortal/DB/mySQL [jtel@acd-db1 mySQL]$ ./update_all.sh root:fireball@localhost Updating Database..................... CONGRATULATIONS: no errors during update. [jtel@acd-db1 mySQL]$ cd ~/shared/JTEL/DB [jtel@acd-db1 DB]$ ./update_all.sh root:fireball@localhost Updating database.......... CONGRATULATIONS: no errors during update. [jtel@acd-db1 DB]$ cd ~/shared/acme/DB [jtel@acd-db1 DB]$ ./update_all.sh root:fireball@localhost Updating database... CONGRATULATIONS: no errors during update. [jtel@acd-db1 DB]$
Nach der Erstinitialisierung müssen noch einige Werte an die Systemumgebung angepasst werden. Um dies zu vereinfachen, wird eine spezielle Datenbankprozedur aufgerufen, die nahezu alle benötigten Anpassungen für ein Standard-System vornimmt. Diese Prozedur muss folgende Parameter übergeben bekommen:
Parameter | Bedeutung | Wert in diesem Beispiel | |
---|---|---|---|
1 | _softwareHome | UNC des Verzeichnisses in dem das jtel-System alle Daten unterbringt. Dort befinden sich z.B. die Verzeichnisse Data , LogFiles und LogFilesCall . | '//acd-lb/shared/' |
2 | _dataHome | UNC des Verzeichnisses in dem das jtel-System alle Programmdateien vorfindet. Dort befinden sich z.B. die Verzeichnisse JTELCarrierPortal und JTEL . | '//acd-lb/shared/' |
3 | _webServerList | Komma-Separierte Liste aller WEB-Application-Server. | 'acd-jb1,acd-jb2' |
4 | _telServerList | Komma-Separierte Liste aller TEL-Server die Call-Flow-Applikationen ausführen. | 'acd-tel1' |
5 | _daemonServer | TEL-Server auf dem die Verwaltungsapplikationen ausgeführt werden. | 'acd-tel1' |
6 | _loadBalancer | Name des Servers auf dem die Rolle LB ausgeführt wird. | 'acd-lb' |
7 | _https | TRUE , falls der Load Balancer die Dienste über HTTPS zur Verfügung stellt, FALSE falls nicht. | FALSE |
ACHTUNG
Bei den UNC bzw. Pfadangaben gelten folgende Regeln:
- Das Trennzeichen ist ein / (slash) und kein \ (backslash)
- Die Pfade müssen mit / enden
Der Aufruf erfolgt mittels folgendem Befehl:
mysql -u root -pfireball -v -e "CALL JTELWeb.Hardstyle_ReconfigureFullSystem('//acd-store/shared/','//acd-store/shared/','acd-jb1,acd-jb2','acd-tel1','acd-tel1','acd-lb',FALSE)"
Damit ist die Einrichtung der Rolle DATA abgeschlossen.
Weiterführende Links
Keep only bin logs for 4 hours
This step is necessary, on servers with a high load and low disk capacity:
echo "FLUSH LOGS;" > /home/jtel/purge.sql echo "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 4 HOUR;" >> /home/jtel/purge.sql echo '#!/bin/bash' > /home/jtel/purge.sh echo "mysql -uroot -pfireball < /home/jtel/purge.sql" >> /home/jtel/purge.sh chmod 700 /home/jtel/purge.sh mv /home/jtel/purge.sh /etc/cron.hourly/