Für dieses Beispiel brauchen wir 2 Tabellen, genaugenommen je eine Quell – und Zieltabelle.

CREATE TABLE src (
    src_id INT(11) NOT NULL AUTO_INCREMENT,
    src_value1 VARCHAR(255) NOT NULL,
    src_value2 VARCHAR(255) NOT NULL,
    src_ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (src_id),
    KEY idx_src_ts (src_ts)
) ENGINE=InnoDB;
 
CREATE TABLE tgt (
    tgt_id INT(11) NOT NULL,
    tgt_value1 VARCHAR(255) NOT NULL,
    tgt_value2 VARCHAR(255) NOT NULL,
    tgt_ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (tgt_id),
    KEY idx_tgt_ts (tgt_ts)
) ENGINE=InnoDB;

Ein paar Testdaten dazu:

INSERT INTO src (src_value1, src_value2) 
VALUES
    ('a', 'aa'),
    ('b', 'bb'),
    ('c', 'cc'),
    ('d', 'dd'),
    ('e', 'ee'),
    ('f', 'ff'),
    ('g', 'gg'),
    ('h', 'hh');

Im Gegensatz zu MERGE ist es unter mySQL nicht möglich, die Verknüpfung direkt zu bestimmen (.. ON sourcetable.key = targettable.somekey.. ). Unter mySQL werden automatisch alle Unique Indexe angewendet (UNIQUE/PRIMARY).
In den Beispieltabellen wurden daher jeweils ein Primary Key definiert, auf welchem der “Merge” stattfinden soll. Wird ein solcher beim Einfügen in die Zieltabelle “verletzt”, kann der Datensatz über ON DUPLICATE KEY abgefangen und weiter verarbeitet werden. Das ganze ist somit nichts anderes als ein normaler Insert mit “Errorhandling”.

Beispiel

INSERT
INTO
    tgt
    (   
        tgt_id,
        tgt_value1,
        tgt_value2
    )
SELECT
    src_id,
    src_value1,
    src_value2
FROM
    src
ON DUPLICATE KEY 
UPDATE 
    tgt_value1 = VALUES(tgt_value1),
    tgt_value2 = VALUES(tgt_value2)

Existiert beim Insert der Key in der Zieltabelle bereits, werden lediglich alle (definierten) Attribute des Datensatzes aktualisiert, und in unserem Fall der Timestamp (ON UPDATE ..) aktualisert. Sind die Attribute des Datensatzes unverändert – erfolgt kein Update.

Das Statement oben kann daher beliebig oft ausgeführt werden – solange sich der Inhalt der Quelltabelle nicht verändert bleiben auch die Informationen inklusive Timestamp in der Zieltabelle unverändert.

Zu Testzwecken verändern wir nun einen Datensatz in der Quelltabelle:

UPDATE src SET src_value2 = 'wohooooooo' WHERE src_value1 = 'a'

Wird nun das “Merge” Statement erneut ausgeführt, wird der betroffene Datensatz auch in der Zieltabelle aktualisiert – und nur dieser.

Natürlich macht es in der Praxis keinen Sinn eine 1:1 Kopie einer Tabelle zu verwalten. Als Quelle kann natürlich auch eine komplexe Abfrage oder ein View dienen, resp. mehrere davon pro Zieltabelle. In diesem Fall muss auf der Zieltabelle der entsprechende Primary-Key, resp. besser Unique-Index angelegt werden.

Im Gegensatz zu den “echten” MERGE-Statements sind hier leider keine zusätzlichen Bedingungen beim Update möglich.

Anwendung:

./xe-remove-template.sh "template-name"

xe-remove-template.sh

#!/bin/bash
## xe-remove-template.sh, remove template by name on local xenserver instance
## Author:  Michael Bieri <mb@alonso.ch>
## Warning: This script has no brain - use your own!
 
UUID=$(xe template-list name-label="$1" --minimal)
 
if [[ -z $UUID ]] ; then
    echo "Sorry - Template not found"
    echo "Usage: $0 <template-name>"
    exit 1
fi
 
echo "using UUID: $UUID"
 
xe template-param-remove uuid=$UUID param-name=other-config param-key=default_template
xe template-uninstall template-uuid=$UUID force=true
 
echo "Done"

Das Script gibts auch hier als Download.

Ist aber grundsätzlich kein Hexenwerk – so gehts:

Sofern bestehende Datenbanken vorhanden sind – Backup erstellen! Ich gehe davon aus dass es hierzu kein HowTo braucht

Alte Installation bereinigen, sofern vorhanden:

apt-get remove mysql-server mysql-common --purge && apt-get autoremove

Danach sollte die “asynchronous I/O library”, kurz AIO aus dem Repository installiert werden – damit kann die spätere Performance von InnoDB massiv verbessert werden.

apt-get install libaio-dev

Analog zu Debian, sollte mySQL auch weiterhin unter einem eigenen Benutzer laufen, dazu legen wir diesen mit entsprechender Gruppe an, sofern notwendig.

useradd mysql
groupadd mysql

Danach werden die benötigten Ordner auf dem Filesystem angelegt und mit den nötigen Rechten versehen. In diesem Beispiel wird die Struktur analog zur normalen Packetinstallation aufgebaut. Diese sollte aber wenn möglich weiter optimiert werden. Ein paar Gedanken dazu sind in einem anderen Artikel zu finden.

mkdir /var/log/mysql && chown -R mysql:mysql /var/log/mysql
mkdir -p /var/run/mysqld && chown -R mysql:root /var/run/mysqld && chmod -R 755 /var/run/mysqld
mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql && chmod -R 700 /var/lib/mysql

Als nächstes brauchen wir nun das aktuellste “Linux Generic Tar Archive” von mySQL:
http://www.mysql.com/downloads/mysql/#downloads

Wählen sie unbedingt das korrekte Packet. Sollten sie unsicher sein bezüglich 32 oder 64 Bit – Fragen sie doch mal ihr System dazu

getconf LONG_BIT

In meinem Fall wurde die Version 5.5.15 (64 Bit) von Switch.ch heruntergeladen und entpackt:

cd /usr/local/src/ && mkdir mysql5.5 && cd mysql5.5
wget http://dev.mysql.com/get/Downloads/MySQL-5.5/mysql-5.5.15-linux2.6-x86_64.tar.gz/from/http://mirror.switch.ch/ftp/mirror/mysql/ -O mysql-5.5.15-linux2.6-x86_64.tar.gz
tar xzvf mysql-5.5.15-linux2.6-x86_64.tar.gz

In meinem Setup werden die Dateien anschliessen nach /usr/share/mysql verschoben und an den User mysql zugewiesen:

mv mysql-5.5.15-linux2.6-x86_64 /usr/local/mysql
chown mysql:mysql /usr/local/mysql/ -R

Als nächstes muss das mySQL-Bin Verzeichniss noch in den Path aufgenommen werden:

export PATH=/usr/local/mysql/bin:$PATH

Wenn alles klappt – sollte mySQL nun startklar sein. Ein kleiner Test schaded aber sicherlich nicht:

mysql -V && mysqld -V

Sollte folgendes ans Licht bringen:

mysql  Ver 14.14 Distrib 5.5.15, for linux2.6 (x86_64) using readline 5.1
mysqld  Ver 5.5.15 for linux2.6 on x86_64 (MySQL Community Server (GPL))

Wenn alles geklappt hat, sollte noch die /etc/profile mit dem neuen Pfad ergänz werden damit diese Änderung permant wird. Auszug:

...
if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/mysql/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/mysql/bin"
fi
export PATH
...

Nun brauchen wir noch die Konfiguration als /etc/mysql/my.cnf. Hierzu gibt es gute Templates welche übernommen werden können. In meinem Beispiel wurde die my-innodb-heavy-4G.cnf gewählt – es gäbe aber noch diverse Alternativen – am identischen Ort.

cp /usr/local/mysql/support-files/my-innodb-heavy-4G.cnf /etc/my.cnf

Folgende Anpassungen sind hier notwendig (anpassen/ergänzen):

[client]
socket          = /var/run/mysqld/mysqld.sock

[mysqld]
socket          = /var/run/mysqld/mysqld.sock
basedir         = /usr/local/mysql
datadir         = /usr/local/mysql/data
tmpdir          = /tmp
log_error       = /var/log/mysql/error.log

init.d Script erstellen:

cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql && chmod +x /etc/init.d/mysql

Hier sind nun noch 2 weitere Anpassungen notwendig:

basedir=/usr/local/mysql
datadir=/var/lib/mysql/data

Basisdatenbanken anlegen:

/usr/local/mysql/scripts/mysql_install_db --user=mysql --basedir=/usr/local/mysql

Fertig – ein erster Startversuch:

/etc/init.d/mysql start

Sicherheits-Konfiguration setzten, dafür braucht es allerdings noch einen Symlink für den Socken:

ln -s /var/run/mysqld/mysqld.sock /tmp/mysql.sock
/usr/local/mysql/bin/mysql_secure_installation

Wird AIO auch wirklich angewendet? Ein Blick ins Log hilft weiter, folgender Eintrag muss erscheinen:

****** **:**:** InnoDB: Using Linux native AIO

Wenn alls OK ist – Server automatisch mit Bootprozess starten:

update-rc.d mysql defaults

Installation der Pakete:

apt-get install snmp

Wer auch zukünftig seine OID’s auflösen möchte, muss sich nun neu im Non-Free Repository bedienen. Dort steht das entsprechende Paket “snmp-mibs-downloader” bereit.

apt-get install snmp-mibs-downloader

Das wars, der SNMPD-Deamon müsste mal “laufen”. Test mittels dem entsprechenden init.d Script möglich

/etc/init.d/snmpd status

Dort müsste man den Erfolg der bisher äussert komplexen Installation nun mittels “snmpd is running” bestätigt kriegen.

Weiter gehts mit der Konfiguration:

Offiziell steht das Tool snmpconf bereit, mit welchem man per Wizzard den Dienst konfigurieren kann. Ich pers. finde dieses Tool allerdings eher verwirrend und ineffizient. In diesem Beispiel sollen lediglich die Systeminformationen plus ein paar “externe” Scripts auf Distanz mittes SNMP v1/v2 abgefragt werden können, daher reicht eine recht magere Konfiguration.

/etc/snmp/snmpd.conf

# Netzwerk
agentAddress  udp:161
 
#Zugriffsteuerung
rocommunity public nagioshost.hallo.welt
 
# Kontaktinformationen
syslocation Ich bin hier
syscontact ich@hallo.welt
 
# Systemchecks
includeAllDisks  10%
load   12 10 5
 
#Erweiterungen
exec meintest   /usr/local/bin/meintest.sh

Erwähnenswert ist hier der “neue” Parameter agentAddress , welcher den Deamon standartmässig nur auf localhost (udp:127.0.0.1:161) bindet. Hier wahlweise die gewünschte Interface-Adresse verwenden, oder wie in meinem Beispiel auf allen IP’s des Systems horchen lassen. Alle übrigen Parameter haben sich bei Squeeze wenig verändert. Die Zugriffsteuerung wurde sogar wesentlich vereinfacht über ein view konzept – welches im aufgezeigten Beispiel allerdings komplett weggelassen wurde. Die definierte Host/Community Kombination hat so einen kompletten Lesezugriff.

Den Deamon neu starten – fertig:

/etc/init.d/snmpd restart

Auch hier lohnt es sich danach ein weiteres mal den “status” abzufragen:

/etc/init.d/snmpd status

Sofern vorhanden, müssen nun noch die entsprechenden Regeln in der Firewall ergänzt werden (TCP/UDP Port 161), damit der Zugriff auf Distanz auch wirklich klappt.

Alte Zertifikate sichern:

cd /etc/courier/
mv imapd.pem imapd.pem.old
mv pop3d.pem pop3d.pem.old

Neue Zertifikate erstellen:

mkimapdcert
mkpop3dcert

Courier-SSL Dienste neu starten:

/etc/init.d/courier-pop-ssl restart && /etc/init.d/courier-imap-ssl restart

So – schon hat man wieder 1 Jahr lang Ruhe..

Sehr informativ sind die Table Schemas.

Folgendes Query listet alle Tabellen, deren Storage Engine, Kollation und die Anzahl Datensätze zurück:

SELECT table_schema, table_name, engine, table_collation, table_rows 
from information_schema.tables 
where table_schema like 'mydb%';

Resultat (z.B. WordPress Blog DB):

mysql> select table_schema, table_name, engine, table_collation, table_rows 
from information_schema.tables 
where table_schema like 'mydb%';
+--------------+-----------------------+--------+-----------------+------------+
| table_schema | table_name            | engine | table_collation | table_rows |
+--------------+-----------------------+--------+-----------------+------------+
| mydb1  | wp_commentmeta        | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_comments           | MyISAM | utf8_general_ci |          3 |
| mydb1  | wp_contact_form_7     | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_links              | MyISAM | utf8_general_ci |          2 |
| mydb1  | wp_options            | MyISAM | utf8_general_ci |        269 |
| mydb1  | wp_postmeta           | MyISAM | utf8_general_ci |         69 |
| mydb1  | wp_posts              | MyISAM | utf8_general_ci |        103 |
| mydb1  | wp_prli_clicks        | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_prli_groups        | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_prli_link_metas    | MyISAM | utf8_general_ci |          0 |
| mydb1  | wp_prli_links         | MyISAM | utf8_general_ci |          1 |
| mydb1  | wp_term_relationships | MyISAM | utf8_general_ci |        163 |
| mydb1  | wp_term_taxonomy      | MyISAM | utf8_general_ci |         56 |
| mydb1  | wp_terms              | MyISAM | utf8_general_ci |         50 |
| mydb1  | wp_usermeta           | MyISAM | utf8_general_ci |         16 |
| mydb1  | wp_users              | MyISAM | utf8_general_ci |          1 |
+--------------+-----------------------+--------+-----------------+------------+
16 rows in set (0.74 sec)

Natürlich sind hier auch weitere Informationen abrufbar. Erste Hilfe bietet hier einmal mehr die mySQL Dok

Ein einfaches

SHOW FULL PROCESSLIST;

auf der mySQL-Konsole dieses Servers brachte folgendes Query mit sehr kurzen Intervallen und einer grossen Laufzeit zum vorschein:

SELECT * FROM hits ORDER by userid DESC

Somit war auch die verdächtige Datenbank – und dadurch auch der verantwortliche Account erruiert. Ein kurzer Blick auf das Schema dieser Datenbank/Tabelle zeigte folgendes:

• > 1’000’000 Datensätze!
• Kein Index auf userid!

Als erstes wurde mal userid indexiert, was zwar die Queryperformance deutlich verbesserte – aber die Last des Servers immernoch überdurchschnittlich beanspruchte.

Ich konnte mir spontan nicht erklären, wesshalb jemand den kompletten Inhalt dieser Tabelle auslesen sollte. Alleine der fehlende Index und das “Select *” waren für mich ein Indiz, dass hier KEIN Profi am Werk war. Mich packte der Ergeiz und ich warf einen Blick auf den PHP-Code der entsprechenden Applikation. Es handelte sich dabei um ein gut frequentiertes Toplisten-Script. Irgendwo im Code fand ich folgendes:

..
{
  $useridgen=mysql_query("SELECT * FROM hits ORDER BY userid DESC");
  $idgenaray=mysql_fetch_array($useridgen);
  $userid=$idgenaray[userid]+1;
}
..

Toll, diese Funktion macht also nichts anderes als die nächste ID für einen Datenbankeintrag zu ermitteln.
Auto_Increment war hier offenbar ein Fremdwort..

Nach einer Rücksprache mit dem betroffenen Kunden wurde die Applikation so minimal wie möglich angepasst.

{
  $useridgen=mysql_query("SELECT max(userid) as userid FROM hits");
  $idgenaray=mysql_fetch_array($useridgen);
  $userid=$idgenaray[userid]+1;
}

Das neue Query liefert durch den SELECT max() nur noch genau 1 Datensatz zurück (statt > 1’000’000 vorher)! – erfüllt aber genau dieselbe Funktion innerhalb dieses Scriptes. Das Script selbst musste somit nicht weiter angepasst werden.

Die Auswirkung dieses Korrektur lässt sich auf folgenden Graphen auf beeindruckende Art und Weise erkennen:

Praxisbeispiel:
Ein Kundenserver viel immer wieder durch schlechte Performance auf. Es handelte sich dabei um eine Forensoftware von Woltlab, welche mit ein paar Hacks erweitert wurde. Insgesammt umfasst die Datenbank an die 1.5 Millionen Posts in 300’000 Threads. Das Datenvolumen der Datenbank lag zu diesem Zeitpunkt bei rund 1.4GB. Zu Stosszeiten waren jeweils an die 250 User und Bots unterwegs..

Ein einfaches

SHOW FULL PROCESSLIST;

auf der mySQL-Konsole brachte folgendes Query mit einer sehr grossen Laufzeit zum vorschein:

SELECT
bb2_threads.*,
bb2_icons.*,
bb2_boards.*,
bb2_users.username as lastposter
FROM bb2_threads
LEFT JOIN bb2_icons USING (iconid)
LEFT JOIN bb2_boards ON (bb2_threads.boardid=bb2_boards.boardid)
LEFT JOIN bb2_users ON (bb2_threads.lastposterid=bb2_users.userid)
WHERE bb2_threads.closed!=3 
ORDER BY bb2_threads.lastposttime DESC LIMIT 0, 5

Dieses Query ermittelt also die 5 aktuellsten Threads sammt Titel, Author und die entsprechenden ID’s für die Verlinkung und zeigt diese infos auf der Startseite an. Das Query hatte unverändert auf der Konsole trotz allen notwendigen Indexen eine Laufzeit von gut 3s – verursacht durch die gigantische Datenmenge und den notwendigen Filesort.

Nachdem ich mich in das Datenbankschema eingearbeitet habe – konnte ich das Query “etwas” bereinigen:

SELECT
bb2_threads.threadid,
bb2_threads.views,
bb2_threads.lastposterid,
bb2_threads.topic,
bb2_threads.lastposter
FROM bb2_threads
LEFT JOIN bb2_boards ON (bb2_threads.boardid=bb2_boards.boardid)
WHERE bb2_threads.closed!=3 
ORDER BY bb2_threads.lastposttime DESC LIMIT 0, 5

Der Output ist 100% identisch zum Original. Die Abfrage dauert jetzt allerdings nur noch knapp 0.2s!

Nur diese eine Anpassung hatte folgende Auswirkung auf die Serverlast (Ab KW51):

• Slow Query Log
• Max Connections
• Worker Threads
• Key Buffer
• Query Cache
• Sort Buffer
• Joins
• Temp Tables
• Table (Open & Definition) Cache
• Table Locking
• Table Scans (read_buffer)
• Innodb Status

Kompatibel mit allen gängigen mySQL Versionen.

Bereitgestellt wird der Tuning Primer von Day32.com. Download: mySQL Tuning primer

• Verwenden sie einen möglichst aktuellen Kernel
• Verwenden möglichst keine Hardware-Virtualisierung (z.B. VMware, Virtual PC).
• Legen sie die mySQL-Daten auf eigenes Filesystem/Partition, bzw. idealerweise auf eigene Disks
• Verwenden sie für diese Datenpartition ein Raid-Setup mit hohem Schreibdurchsatz, also z.B. Raid1 statt Raid5. Dieser Punkt gewinnt an Priorität bei Datenbanken mit einem hohen Anteil an Insert/Update/Delete Statements.
• Wählen sie bewusst das passende Filesystem und die Parameter für die Datenpartition. Hier finden sie einige Benchmarks zu diesem Thema. Beachten sie unbedingt die entsprechenden Risiken und Eigenschaften.
• Mounten sie das Filesystem mit der Option “noatime”. Dadurch wird vermieden, dass der Kernel bei jedem Zugriff auf eine Datendatei den Inode aktualisert.

Das Optimieren mittels der my.cnf wird in einem späteren Artikel behandelt.