Monthly Snap April > NETWAYS Web Services, Braintower, OSBConf, Teamweekend, AKCP, OSDC, GitLab CE, Galera, GitHub, Puppet

In April, Isabel startet with announcing a new Software Update for Braintower and Martin K. continued with a new NETWAYS Web Services tool: Rocket.Chat Hosting.

Then Julia announced the call for papers for the Open Source Backup Conference 2017 in Cologne while Marius wrote about the end of Ubuntu 12.04 LTS.

Later in April, Marius H. gave some practical tips for the Galera Cluster and Dirk wrote about contributing to projects on GitHub.

Then Martin K. presented the next NETWAYS Web Services App, GitLab CE Hosting, and Julia told about the latest OSDC-News.

Furthermore, Catharina reviewed the team event of the commercial departments while Noah told us how to block some Google searches in Google Chrome.

Lennart gave an insight in the monitoring project at htp GmbH and Daniel introduced himself.

Towards the end of April, Isabel told about the latest news concerning the AKCP sensorProbe 2+ and Martin S. explained external monitoring by the Icinga2 satellites at NETWAYS Web Services.

Last but not least, Jean reported on monitoring powershell scripts with Icinga 2, while Lennart went on with part 2 of automated monitoring with Puppet.

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Galera Cluster – Tips für die Praxis

Galera Cluster für MySQL ist mal ein “einfacher” Cluster für MySQL und seit MariaDB Version 10.1 standardmäßig mit an Board. Dadurch erhält man mit ein paar Zeilen Konfiguration einen produktionsfähigen Cluster, um den man sich wenig kümmern muss. In der Praxis allerdings, bieten sich genügend Fallstricke, die es zu meistern gilt.

Die Terminologie

  • Joiner: Neues Member welches dem Cluster hinzugefügt wird
  • Donor: Meldet sich ein Joiner stellt der Cluster einen Lieferanten bereit welcher die Daten auf den Joiner überträgt
  • SST: Snapshot State Transfer – Ist Lücke zum aktuellen Stand zu groß, werden der komplette Stand übertragen
  • IST: Incremental State Transfer – Im laufenden Betrieb werden Änderungen direkt übertragen. Die Änderung ist am Cluster erst verfügbar wenn alle Mitglieder diesen Stand empfangen haben

Tipps

1. SST Vermeiden

Einen kompletten Stand der Daten zu übertragen ist keine gute Idee. Ein Cluster, welcher 1 TB Nutzdaten verwaltet, ist auch nach drei Tagen nicht fertig. Dadurch können stabile Member ihre Integrität verlieren und der Cluster wird instabil. Hat man eine solche Situation erreicht empfiehlt es sich, den kompletten Cluster manuell zu syncen (MySQL Daten löschen und per rsync kopieren – Aber bitte keine Binlogs!).

2. SST Method

Galera bietet verschiedene Methoden um einen SST durchzuführen. Laut Statistik ist SSH die schnellste Methode – D’Accord – Aber der dadurch entstehende Donor ist für Anfragen gelockt und fällt aus dem Cluster. Dadurch wären wir bei Punkt 1 angelangt. Der beste trade-off ist hier xtrabackup-v2. Dadurch wird ein Donor am wenigsten blockiert. Bitte dabei den Benutzer zur MySQL Authentifizierung nicht vergessen – Sonst geht gar nichts!

3. SST Konfiguration

SST und das ausführen auf dem Joiner kann maßgeblich verbessert werden mit folgender MySQL Konfiguration:

[sst]
inno-apply-opts="--use-memory=20G"
compressor="pigz"
decompressor="pigz -d"

Dadurch geben wir dem innobackupex Script, welches auf dem Joiner ausgeführt mehr Speicher um Daten aus den Logs (–apply-log) auszuführen. Weiterhin parallelisieren wir den Vorgang um Daten auf dem Donor zu komprimieren und – guess what – auf dem Joiner zu dekomprimieren.

Um die Transaktionen weiter zu parallelisieren erhöhen wir die Einstellung wsrep_slave_threads auf eine dem System angepasste Anzahl (Anzahl Cores und Auslastung).

4. Dedizierten Donor

Bei großen Datenmengen empfiehlt es sich einen eigenständigen Donor bereitzustellen welcher keine Anfragen entgegen nimmt.

[mysqld]
 wsrep_sst_donor = node-donor

Eventuell sollte man auch Queries mit der Einstellung wsrep_sst_donor_rejects_queries verbieten

5. Locking Queries

Galera ist maximal transparent für Applikationen. Einzig, LOCKING wird nicht akzeptiert. Falls es von der Applikation benötigt wird könnte man mit der Einstellung wsrep_convert_LOCK_to_trx die Queries in Transaktionen kapseln.

6. Provider Cache

Standardmäßig auf 128M eingestellt, enthält dieser Ringpuffer die zu Verfügung stehen write-sets für einen IST. Die Größe sollte man entsprechend hoch wählen. So kann auch bei größeren Lücken immer noch ein IST durchgeführt werden:

[mysqld]
wsrep_provider_options="gcache.size=1G"

Bei entsprechend Arbeitsspeicher oder SSD Storage ist es durchaus eine gute Idee die Datei auf das schnellste Storage zu legen oder eine Lastaufteilung vorzunehmen:

[mysqld]
wsrep_provider_options="gcache.size = 8G; gcache.name = /var/cache/ssd/galera.cache"
7. HAProxy verwenden

Der stabilste Cluster bringt einem gar nichts wenn man nur einen Knoten abfragt. Eine der Stärken von Galera ist es, von allen Knoten zu lesen. Hier sollte man sich Gedanken zur Aufteilung machen:

  • Die schnellsten Knoten zum lesen und in den HAProxy
  • Donor exkludieren
  • Backup members bereitstellen (hot-standby)

Eine Konfiguration können z.B. folgendermaßen aussehen:

backend mysql_pool
  mode tcp
  balance roundrobin
  option mysql-check user haproxy
  option tcpka # keep-alive!
  server galera-donor1   192.168.17.20:3306 check inter 12000 disabled
  server galera-standby1 192.168.17.21:3306 check inter 12000 disabled
  server galera-node3    192.168.17.22:3306 check inter 12000
  server galera-node4    192.168.17.23:3306 check inter 12000
  server galera-node5    192.168.17.24:3306 check inter 12000

Dadurch erhalten wir einen Donor, einen hot-standby und drei read-heads. Durch die HAProxy API kann man das auch je nach Zustand des Cluster zu oder abschalten. Auch wäre eine standortübergreifende Verteilung möglich. Man stelle sich verschiedene Pools in verschiedenen Ländern vor. Je nach Ursprung und Applikation können dann die Anfragen zu den schnellsten read-heads weitergeleitet werden. Dann sollte man sich aber überlegen, z.B.  wsrep_dirty_reads an den Standorten zu verwenden.

8. Bin Logs

Ein richtiger Klassiker der Cluster Pitfalls, die Binary Logs von MySQL. Man würde sie für Galera nicht unbedingt benötigen aber sie bieten Sicherheit beim Crash und helfen einen SST im Falle zu vermeiden. In großen Umgebungen muss man folgendes bedenken:

  • Speicherplatz begrenzen
  • Vorhaltezeit verkürzen
  • An das verfügbare Storage anpassen

Ansonsten dauert ein FLUSH LOGS gerne auch mal 3 Tage und blockiert einen unseren Knoten – Beim Donor besonders schlecht!

Fazit

Für mich ein fantastisches Cluster System für MySQL! Es gibt noch viele gute Tips da draussen und noch viel mehr Möglichkeiten (und auch schmerzen) mit InnoDB / MySQL Konfiguration. Es funktioniert auch leider beim Galera Cluster nichts ohne vorher die eigene Rübe einzuschalten 😉

Links

 

Marius Hein

Autor: Marius Hein

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Numeric datatypes as primary key in databases

Most likely primary keys in databases are numbers. But what happens, when an administrator uses the wrong numeric data type? In the worst case, databases can’t write down entries anymore.

For example, if an administrator wants to write customer information into the databases and wants to use the customerID itself as the primary key, then the numeric data type “TINYINT” would cause that only 255 entries can be written. But on the other hand the “BIGINT” numeric data type, could be too large for smaller databases.
So when you are setting up a database, you should think about how many entries will be written the next months/years and think about which datatype is the right one for your setup. Also you should think about if you should use the data types unsigned or not. This value will change the range of the datatypes.

Typ signed unsigned
Min Max Min Max
TINYINT -128 +127 0 255
SMALLINT -32.768 +32.767 0 65.535
MEDIUMINT -8.388.608 +8.388.607 0 16.777.215
INT/INTEGER -2.147.483.647 +2.147.483.646 0 4.294.967.295
BIGINT -263 +263 – 1 0 264 – 1

Another example:
If an administrator wants to store 60000 customer information in the database, he should use at least a “SMALLINT”. Should he use the unsigned version or not? Lets have a look.
With the signed data type he has a range from -32.768 up to +32.767, but no customerID (primary key as mentioned above) has a negative number, so a “unsigned SMALLINT” would be necessary.

The case, that you thought about the questions above but your data type got out of range, could happen. There is a way to change the datatype and to increase the range in a simple way.
*ALTER TABLE tablename MODIFY column MEDIUMINT UNSIGNED;*
But remember: The larger your database is, the longer will it take to do such changes!

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Running RedHat SCL PostgreSQL with Puppet

On a test system for a customer I wanted to bring up a newer PostgreSQL version on CentOS 7 (same for RHEL 7). Software Collections (also for RedHat) gives you a neat distribution method that is not very invasive into your existing distribution. So you can install a PostgreSQL 9.4 under RHEL 7 without replacing any of the existing packages. This is a bit tricky in terms of paths, but just works.

I found a relatively simple way to install, configure and run such a SCL with Puppet, with just using the existing PostgreSQL module.

Have fun trying it out and let me know what you think.

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

if exists for Column and Index Migrations in MySQL

Unfortunately MySQL does not provide an SQL statement for conditionally creating a column if it does not already exist. There also does not appear to be an easy way for dropping a column without causing an error if the column doesn’t exist. The same problem also applies to indices. This functionality however is commonly used for idempotent schema updates. Without stored procedures which take care of the changes you are lost. I would like to share a Gist on GitHub which helps for the following schema migrations:

  • Drop index if exists
  • Create index if not exists
  • Create unique index if not exists
  • Drop column if exists
  • Add column if not exists

I am using the INFORMATION_SCHEMA tables for testing for the existence of columns and indices. No special grant is necessary to query from those tables. The stored procedures have the following signature:

Drop index if exists
m_drop_index(table_name, index_name)

Create index if not exists
m_create_index(table_name, index_name, index_columns)

Create unique index if not exists
m_create_unique_index(table_name, index_name, index_columns)

Drop column if exists
m_drop_column(table_name, column_name)

Add column if not exists
m_add_column(table_name, column_name, column_definition)

After importing, you can use them instead of MySQL’s ALTER statements. Here is an example for adding the name column to the table person:

mysql> CALL m_add_column('person', 'name', 'varchar(255)');
Eric Lippmann

Autor: Eric Lippmann

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Vorträge der OSBConf 2016

Nachdem Daniela vor Kurzem ja schon was zu den vorgelagerten Workshops und zum Rahmenprogramm der diesjährigen Open Source Backup Conference in Köln geschrieben hat (siehe: Rauchende Köpfe, knurrende Mägen…), möchte ich noch etwas über die Vorträge dort berichten.

img_0802Nach einer kurzen Begrüßung durch Maik Außendorf von der dass IT ging’s los mit Julius Faubel von der Tandberg Data GmbH. Er referierte über Backup to Tape und stellte anschließend die Produkte der NEOxl, NEOs und der NEOe-Series vor. Gregor Wolf von Red Hat sprach anschließend über die Herausforderungen der Datenexplosion und wie man diese in den Griff bekommen kann.

Die Neuerungen von Bareos 16.2 und deren Roadmap für nächstes Jahr wurde uns von Philipp Storz und Maik Außendorf präsentiert. Neben anderen neuen Features wurde besonders anschaulich auf “Always Incremental” eingegangen, welches besonders bei großen Datenmengen Zeit- und Netzwerkkapazität reduziert.

Vor der ersten Kaffeepause zeigte Erol Ülükmen noch welche besonderen Ansprüche das Clientmanagement mit sich bringt und wie sich das Open Source Clientmanagementsystem Opsi (Open PC Server Integration) mit Bareos integrieren läßt.

Gratien d’haese, der am Tag zuvor auch schon den Workshop zu REAR (Relax-and-Recover) gehalten hatte, erklärte was bei einem Business Continuity Plan zu beachten ist und wie man das darin enthaltene Disaster Recovery mit Bareos und REAR abbilden kann. Einen praktischen und interessanten Einblick wie das Backup bei der Friedrich-Schiller-Universität in Jena mit Bareos durchgeführt wird, gab’s vor der Mittagspause noch von Thomas Otto.

img_0805Gut gestärkt hörte man Jörg Brühe zu, der über Datenbank Backup referierte. Dabei wies er v.a. auf Dringlichkeit und Testmöglichkeiten von Restores hin.

Später stellte Christian Reiß von Symgenius ZFS vor und zeigte wie es mit Bareos zusammenspielt. Das Deployment dafür wurde mit Puppet gelöst, weshalb er auch auf das von ihm geschriebene Bareos-Puppet Modul näher einging.

Tobias Groß präsentierte nach der Kaffeepause am Nachmittag wie sinnvoll ein skalierendes Backup anhand von Bareos Active Clients und Puppet ist, allerdings wurde das dafür benutzte Puppetmodul globalways-bareos leider aktuell noch nicht publiziert. Eine belebte Diskussionsrunde über diverse Themen bildete dann den gelungenen Abschluss der Konferenz, bevor alle Teilnehmer mit einem Lunchpaket im Gepäck den Nachhauseweg antraten.

Die Open Source Backup Conference findet im nächsten Jahr vom 25. bis zum 26. September mit hoffentlich ebenso interessanten Vorträgen sowie einem breiten Publikum wieder in Köln statt, also bis dann!

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Systemadministrator in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. In seiner Freizeit ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.