OSDC 2012

| 3 Kommentare | Keine TrackBacks
Moinsen,

die diesjährige OSDC 2012 war wieder mal goil.
Hier sind meine Vorträge zu MySQL Cluster und  Galera Cluster.

Viel Spaß
Erkan

Im letzten Blogpost wurde Galera als Replikationsersatz (im Vergleich zu MySQL 5.5.21 und MariaDB 5.5.20) gemessen.
GroupCommit von MariaDB ist sehr performant und beeindruckend. Der Vergleich zu MySQL ist legitim aber zu Galera unpassend, da Galera eben mehr bietet, als das Ankommen im relay-log eines Slaves.
Folgend wir mit Galera ein 4-Node Cluster aufgebaut. Hier garantiert Galera, dass alle Änderungen auf allen anderen Nodes (im Gegensatz zu Semisync) ankommen und appliziert werden.

Der Test wurde auf einem Knoten der des 4-node Clusters durchgeführt. Im folgenden Blogpost wird auf zwei der vier Knoten der Lasttest durchgeführt.
Galera bietet zwei Kommuniktionsmöglichkeiten der Knoten an.
  1. Unicast
    Das ist der Default
  2. Multicast
    Einfach Konfiguriert mit.

wsrep_provider_options="gmcast.mcast_addr=239.192.0.11"

Das ist der erste Freiheitsgrad unseres Tests, der zweite ist die Anzahl der Applierthreads welcher im Default 1 ist. Gerade Galera ist in der Lage Änderungen parallel zu applizieren, so scheint hier 1 denkbar schlecht. Konfiguriert wird dies mit:

wsrep_slave_threads=64

Achtung: Es scheint, als könnte dies dynamisch geändert werden. SET/SHOW GLOBAL funktioniert einwandfrei. De Facto passiert da nichts.

1. Test Unicast

Galera Unicast

2. Test Multicast

Galera Multicast
Egal ob Multicast oder Unicast 1 Applierthread ist immer die schlechteste Wahl.
In der folgenden Grafik wird die Differenz der beiden Tests abgebildet. Bei positiven Werten ist Multicast schneller, sonst Unicast.
Galera Diff Multi- Unicast
Das Interpretieren überlasse ich dem geneigtem Leser. Comments welcome.

[UPDATE: Hartmut wollte noch einen anderen Graphen haben: ]
. Galera Diff Multi- Unicast

Viel Spaß
Erkan
Es wird wieder Zeit, sich mit Galera zu beschäftigen. Den Auftakt von mehreren Posts zu Galera macht eine Wiederholung des Tests aus einem früherem  Blogpost. Diesmal mit aktuellen Versionen (MySQL 5.5.21, MariaDB 5.5.20, Galera(MySQL 5.5.21 mit 23.2.1beta ).

Hardware:
  • 2xQuadcore X5550
  • 96GB Ram
  • Raid10 XFS

Idee:
Wir wollen eine HA-Lösung mit Replikation aufbauen. Hierfür wird Semisync(MySQL/MariaDB) und Galera genommen.
Es wird der Durchsatz gemessen und verglichen.
Sollte Semisync in async Replikation zurückfallen ist der Lauf ungültig. Dazu wurde nach jedem Lauf einfach geschaut ob die Ausgabe von
SELECT VARIABLE_VALUE from information_schema.global_status where VARIABLE_NAME='Rpl_semi_sync_master_no_times';
sich erhöht hat. [Update2: Ich habe versäumt zu schauen ob semisync überhaupt läuft. (Rpl_semi_sync_master_status,Rpl_semi_sync_slave_status). Daher waren die Messungen für MariaDB falsch und sind korrigiert worden. Zudem war fälschlicher Weise rpl_semi_sync_master_timeout=40 gesetzt. Das sind 40 Millisekunden :). Der Wert wurde auf den Default 10000 gesetzt. Daher kam es nicht mehr zu Abbrüchen.]

Konfiguration MariaDB/MySQL:

innodb_buffer_pool_size     = 8GB
innodb_buffer_pool_instances= 8
innodb_purge_threads        = 1
innodb_log_file_size        = 128M
innodb_log_files_in_group   = 3
innodb_file_per_table
innodb_adaptive_flushing    = 1
innodb_io_capacity          = 1000
innodb_doublewrite=0
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2

Konfiguration Galera:

wsrep_slave_threads=64

Das ist die Anzahl der 'Applierthreads' für Galera.

Verwendet wurde diesmal sysbench. So wurde der Test mit 10 Tabellen a 50000 Rows durchgeführt.
Für einen schnellen Test wurden je 100.000 Transaktionen mit einer Concurrency von 1,8,16,32,64,128, 256 und 512 gefahren.
Eine Transaktion bestand schlicht aus:

                 1089 Query     BEGIN
                 1089 Query     UPDATE sbtest7 SET c='25883440901-70070313541-17142115205-43175972628-35853834861-09785327216-66363106714-83869798964-358398406
16-91707322347' WHERE id=25108
                 1089 Query     DELETE FROM sbtest7 WHERE id=24792
                 1089 Query     INSERT INTO sbtest7 (id, k, c, pad) VALUES (24792, 25041, '34062177881-28188734657-68032246195-58652219795-64480874925-94656605
246-86334788207-61788576849-66682272200-23433875748', '11856908939-86365001688-81484136798-76782671560-49448389421')
                 1089 Query     COMMIT

Also einem Update, Delete und Insert (variable Werte). Hier der selbst sprechende Graph:


MySQL 5.5.21 konnte ab einer Concurrency von 128 nicht mehr durchgängig im Semisync-Modus bleiben. Daher bricht hier die Messreihe für MySQL ab. Das Fabelhafte Ergebnis von MariaDB ist dem GroupCommit von MariaDB zu verdanken. [Update: Das hat nichts mit GroupCommit zu tun. Da er hier laut Doku nicht zuschlagen kann.Infos sind im Link gleich im ersten Absatz.] MySQL 5.6.x wird auch  mit einer Implementierung kommen.
Galera schlägt sich hier hervorragend. Gerade wenn man bedenke, dass Galera auch Master-Master ermöglicht und damit HA-Lösungen implementiert werden können, welche eben nicht hoffen müssen, dass zum Zeitpunkt des Failovers Semisync aktiv war. Aber selbst das  würde nur heißen, dass die Daten im relay-log des Slaves sind :)

[UPDATE]
Nach einem Chat mit Alexey von Codership den Entwicklern. Wurde eine Kleinigkeit geändert.



Zum einen wurde Percona XtraDB Cluster genommen (eine Schande, dass Galera nicht im Namen vorkommt, wo es doch das essentielle Bestandteil ist.) zum anderen auf dem "Slave"
SET GLOBAL wsrep_provider_options='gcs.fc_limit=1024; gcs.fc_factor=0.9999;';
gesetzt. Jedes für sich hat zu obigem Performancegewinn beigetragen \o/
(BTW: Es gibt noch vieelllle Stellschrauben :)

[Update2]
Fazit: Galera ist nicht nur eine schnellere Replikationstechnik, sondern liefert auch Master-Master. Eine Schmach sich damit nicht näher zu beschäftigen1

Viel Spaß
Erkan

Moin wie im Titel: Die Slides vom LXC Techtalk bei der Telekom. Und ja es gibt sogar einen Videomitschnitt. Auf der GUUG Hamburg habe ich einen ähnlichen Artikel gehalten. Da würde ich die selben Slides nehmen. Aber auch MySQL gehört ja zu meiner Lieblingsbeschäftigung hier hin bitte für die SIG MySQL klicken.

Viel Spaß
Erkan
Moin hier mein Vortrag von der GUUG zu obigem Thema.

Ich nutze für einige Installationen bestimmte Pfade für das plugin-dir.
Bei dem Upgrade auf MySQL 5.5 wurde die Konfiguration nicht mehr gezogen.
Beim direkten Starten vom mysqld $CONF war wieder alles in Ordnung.
Es zeigte sich, dass der Fehler im mysqld_safe liegt.
mysqld_safe meint seit 5.5.? die Option plugin-dir parsen zu müssen.
Hierfür wurde die Funktion parse_arguments() erweitert.
#v+
177       --plugin-dir=*) PLUGIN_DIR="$val" ;;
#v-

Folgender Code greift auf die Variable zu (wenn die denn gesetzt wurde):
421 if [ -n "${PLUGIN_DIR}" ]; then
422   plugin_dir="${PLUGIN_DIR}"
423 else
424   # Try to find plugin dir relative to basedir
425   for dir in lib/mysql/plugin lib/plugin
426   do
427     if [ -d "${MY_BASEDIR_VERSION}/${dir}" ]; then
428       plugin_dir="${MY_BASEDIR_VERSION}/${dir}"
429       break
430     fi
431   done
432   # Give up and use compiled-in default
433   if [ -z "${plugin_dir}" ]; then
434     plugin_dir='/usr/local/mysql/lib/plugin'
435   fi
436 fi


Dummerweise wird die Funktion zum Parsen der Config erst später aufgerufen :/
488 parse_arguments `$print_defaults $defaults --loose-verbose mysqld server`
494 parse_arguments `$print_defaults $defaults --loose-verbose mysqld_safe safe_mysqld`
495 parse_arguments PICK-ARGS-FROM-ARGV "$@"

Ergo ist es egal was konfiguriert wurde. Da zum Zeitpunkt des ersten Code-Schnipsels $PLUGIN_DIR immer leer ist.

Bugreport: http://bugs.mysql.com/bug.php?id=63862

Für jene, welche einen schnellen Würgaround brauchen, einfach
 "--datadir=$DATADIR" "--plugin-dir=$plugin_dir" "$USER_OPTION"
durch
"--datadir=$DATADIR"  "$USER_OPTION"
ersetzen.

Viel Spaß
Erkan

Slides DOAG 2011

| Keine Kommentare | Keine TrackBacks
Moinsen,

hier die Slides zu meinen MySQL Vorträgen auf der DOAG 2011.
Partitionieren ueber Rechnergrenzen hinweg und MySQL kann auch NoSQL.

Viel Spaß
Erkan


MySQL hat seit einiger Zeit Previews auf neue Funktionalitäten in MySQL zum Anschauen zur Verfügung gestellt.
Folgend schauen wir uns mysql-5.6.4-labs-innodb-memcached an. Die Grundidee ist, dass quasi an MySQL vorbei direkt auf die Storage Engine zugegriffen wird. So wird der Overhead des SQL Parsers/Optimisers, wie auch der des Verbindungsaufbau gespart.

Ist das Paket installiert, muß das memcached Plugin noch installiert werden. Vorab sind die Verwaltungstabellen - welche sich in scripts/innodb_memcached_config.sql befinden - zu installieren. (mysql < scripts/innodb_memcached_config.sql )
Ein Blick in die Datei verrät, dass das memcached Plugin ein eigenes Schema (innodb_memcache) zum Verwalten des Zugriffes von Datenbankabfragen benötigt/erstellt.
Die Tabelle containers:

mysql> show create table containers\G
*************************** 1. row ***************************
       Table: containers
Create Table: CREATE TABLE `containers` (
  `name` varchar(50) NOT NULL,
  `db_schema` varchar(250) NOT NULL,
  `db_table` varchar(250) NOT NULL,
  `key_columns` varchar(250) NOT NULL,
  `value_columns` varchar(250) DEFAULT NULL,
  `flags` varchar(250) NOT NULL DEFAULT '0',
  `cas_column` varchar(250) DEFAULT NULL,
  `expire_time_column` varchar(250) DEFAULT NULL,
  `unique_idx_name_on_key` varchar(250) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> select * from containers;
+------+-----------+-----------+-------------+---------------+-------+------------+--------------------+------------------------+
| name | db_schema | db_table  | key_columns | value_columns | flags | cas_column | expire_time_column | unique_idx_name_on_key |
+------+-----------+-----------+-------------+---------------+-------+------------+--------------------+------------------------+
| aaa  | test      | demo_test | c1          | c2            | c3    | c4         | c5                 | PRIMARY                |
+------+-----------+-----------+-------------+---------------+-------+------------+--------------------+------------------------+
1 row in set (0.00 sec)

Das Skript innodb_memcached_config.sql hat nicht nur diese Tabelle erstellt sondern - wie auch bei den folgenen Tabellen - auch noch einen Eintrag eingefügt.
Jede Zeile in der Tabelle containers ist definiert auf welche Tabelle memcached zugreift. Die Spalte name dient hier dazu auch mehrere (Ziel)Tabellen zu definieren. Derzeit wird nur eine Tabelle unterstützt. Mir ist auch nicht klar wie via memcached mehr als eine Tabelle unterstützt werden soll. (Ich habe gehört, dass dies dadurch erreicht werden soll, indem die keys aus name:memcachekey bestehen werden sollen.)

db_schema/db_table verweisen auf das konkrete Schema/Tabelle.Die Spalten
key_columns, value_columns, flags, cas_column, expire_time_column sind dem memcached Protokoll geschuldet. Auf dieses gehe ich - unter anderem wegen meiner Unwissenheit bezüglich des Protokolls - nicht ein. Die Spalte unique_idx_name_on_key enthält den Namen des Indexes (welcher UNIQUE sein muß) auf key_columns (hier c1).
So ist ersichtlich, dass Tabellen, welche via dem memcached Plugin zugreifbar sein sollen, dem obigem Format entsprechen müssen. Memcached ist ein simplers Key (key_colums) Value (value_columns) Store. Das memcached Plugin erlaubt unter value_columns mehrere Spalten anzugeben. Da das memcached Protokoll aber nur Key Value kann, bietet das Plugin an einen Separator zu definieren. So wird via memcached ein String (Value) übergeben welches das Plugin nach dem Trenner teilt und in die passenden Spalten schreibt. Zu definieren ist der Trenner in der Tabelle config_optioins:

mysql> show create table config_options\G
*************************** 1. row ***************************
       Table: config_options
Create Table: CREATE TABLE `config_options` (
  `name` varchar(50) NOT NULL,
  `value` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> select * from config_options;
+-----------+-------+
| name      | value |
+-----------+-------+
| separator | |     |
+-----------+-------+

Es ist davon auszugehen, dass hier noch weitere Konfigurationsmöglichkeiten kommen werden. Eine weitere Tabelle ist die cache_policies:

mysql> show create table cache_policies\G
*************************** 1. row ***************************
       Table: cache_policies
Create Table: CREATE TABLE `cache_policies` (
  `policy_name` varchar(40) NOT NULL,
  `get_policy` enum('innodb_only','cache_only','caching','disabled') NOT NULL,
  `set_policy` enum('innodb_only','cache_only','caching','disabled') NOT NULL,
  `delete_policy` enum('innodb_only','cache_only','caching','disabled') NOT NULL,
  `flush_policy` enum('innodb_only','cache_only','caching','disabled') NOT NULL,
  PRIMARY KEY (`policy_name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Während in der Tabelle containers noch angelegt ist auf mehrere Tabellen zuzugreifen, ist dies hier nicht vorgeshen, die Einstellungen pro Tabelle vorzunehmen.
Daher ist das als Konfiguration für alle Tabellen zu interpretieren.
Die genaue Konfiguration wie auch eine auführliche Einleitung ist hier zu finden.
Ärgerlich ist, dass Änderungen in den cache_policies erst nach einem Restart des Servers ziehen.

Doch bisher haben wir die Installation des Plugin versäumt:

mysql> INSTALL PLUGIN daemon_memcached SONAME 'libmemcached.so';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * from  INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME='daemon_memcached'\G
*************************** 1. row ***************************
           PLUGIN_NAME: daemon_memcached
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: DAEMON
   PLUGIN_TYPE_VERSION: 50604.0
        PLUGIN_LIBRARY: libmemcached.so
PLUGIN_LIBRARY_VERSION: 1.3
         PLUGIN_AUTHOR: Jimmy Yang
    PLUGIN_DESCRIPTION: Memcached Daemon
        PLUGIN_LICENSE: GPL
           LOAD_OPTION: ON
1 row in set (0.00 sec)

Folgende Variablen sind zu setzen:

mysql> show global variables like 'daemon_memcached%';
+----------------------------------+------------------+
| Variable_name                    | Value            |
+----------------------------------+------------------+
| daemon_memcached_enable_binlog   | OFF              |
| daemon_memcached_engine_lib_name | innodb_engine.so |
| daemon_memcached_engine_lib_path |                  |
| daemon_memcached_option          |                  |
| daemon_memcached_r_batch_size    | 1048576          |
| daemon_memcached_w_batch_size    | 32               |
+----------------------------------+------------------+

Es handelt sich hierbei um read-only Variablen. So sind diese auch nicht zur Laufzeit zu ändern. Interessant ist die Option daemon_memcached_w_batch_size. Zum Steigern der Performance wird nur alles 32 Änderungen committed. Will man nun (in der Verbindung) auch die noch nicht committetten Anweisungen sehen, ist der Transaktions Level anzupassen:

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;


Fazit:

Also mir erschließt sich der Mehrwert der Memcached Erweiterung nicht. Handlersocket z.B. erlaubt den Zugriff auf jede und mehrere Tabellen der Applikation. Das memcached Plugin verlangt eine Tabelle nach einem festgelegtem Format. Die Usability ist bescheiden. Und wenn man meint durch folgendes den mysqld nicht restarten zu müssen, crasht mysqld eben :)

mysql> uninstall PLUGIN daemon_memcached;
Query OK, 0 rows affected (2.00 sec)

mysql> INSTALL PLUGIN daemon_memcached SONAME 'libmemcached.so';
Query OK, 0 rows affected (0.00 sec)



Viel Spaß
Erkan

Beim Rumspielen mit MySQL 5.6 - von der es Previewversionen gibt - fiel auf, dass es neue Tabellen im I_S gibt:

5.5.13:

mysql> show tables like 'INNODB%';
+----------------------------------------+
| Tables_in_information_schema (INNODB%) |
+----------------------------------------+
| INNODB_CMP_RESET                       |
| INNODB_TRX                             |
| INNODB_CMPMEM_RESET                    |
| INNODB_LOCK_WAITS                      |
| INNODB_CMPMEM                          |
| INNODB_CMP                             |
| INNODB_LOCKS                           |
+----------------------------------------+

5.6.2:

mysql> SHOW TABLES LIKE 'INNODB%';
+----------------------------------------+
| Tables_in_information_schema (INNODB%) |
+----------------------------------------+
| INNODB_CMPMEM                          |
| INNODB_TRX                             |
| INNODB_BUFFER_PAGE                     |
| INNODB_LOCK_WAITS                      |
| INNODB_SYS_TABLESTATS                  |
| INNODB_CMP                             |
| INNODB_SYS_COLUMNS                     |
| INNODB_CMPMEM_RESET                    |
| INNODB_SYS_FOREIGN_COLS                |
| INNODB_BUFFER_PAGE_LRU                 |
| INNODB_BUFFER_POOL_STATS               |
| INNODB_CMP_RESET                       |
| INNODB_SYS_FOREIGN                     |
| INNODB_METRICS                         |
| INNODB_SYS_INDEXES                     |
| INNODB_LOCKS                           |
| INNODB_SYS_FIELDS                      |
| INNODB_SYS_TABLES                      |
+----------------------------------------+

Betrachten wir uns die INNODB_SYS_FOREIGN% Tabellen. Diese erlauben es für InnoDB Tabellen einfach an die Foreign Keys (FK) heran zu kommen. In der Datenbank existiert ein FK kind -> papa.

mysql> select * from INNODB_SYS_FOREIGN;
+------------------+-----------+-----------+--------+------+
| ID               | FOR_NAME  | REF_NAME  | N_COLS | TYPE |
+------------------+-----------+-----------+--------+------+
| test/kind_ibfk_1 | test/kind | test/papa |      1 |    1 |
+------------------+-----------+-----------+--------+------+
1 row in set (0.00 sec)

mysql> select * from INNODB_SYS_FOREIGN_COLS;
+------------------+--------------+--------------+-----+
| ID               | FOR_COL_NAME | REF_COL_NAME | POS |
+------------------+--------------+--------------+-----+
| test/kind_ibfk_1 | id2          | id           |   0 |
+------------------+--------------+--------------+-----+
1 row in set (0.00 sec)

Über INNODB_SYS_FOREIGN erhalten wir die verknüpften Tabellen. TYPE = 1 meint hier ON DELETE CASCADE. Imho nicht wirklich lesbar, vielleicht hätte man sich bei TYPE für den Typ SET entscheiden sollen :)

Die Tabelle INNODB_SYS_FOREIGN_COLS verrät uns die Spalten des FK.
Beide verknüpft:  

mysql> select concat(FOR_NAME,":",FOR_COL_NAME," -> ",REF_NAME,":",REF_COL_NAME)  as FK from INNODB_SYS_FOREIGN_COLS JOIN INNODB_SYS_FOREIGN using(ID);
+-------------------------------+
| FK                            |
+-------------------------------+
| test/kind:id2 -> test/papa:id |
+-------------------------------+


Folgend sehen wir wie dies für MySQL 5.[1,5,6].x auch ohne die neuen Tabellen (annähernd) erledigt werden kann.

mysql> select * from TABLE_CONSTRAINTS WHERE CONSTRAINT_TYPE='FOREIGN KEY';
+--------------------+-------------------+-----------------+--------------+------------+-----------------+
| CONSTRAINT_CATALOG | CONSTRAINT_SCHEMA | CONSTRAINT_NAME | TABLE_SCHEMA | TABLE_NAME | CONSTRAINT_TYPE |
+--------------------+-------------------+-----------------+--------------+------------+-----------------+
| def                | test              | kind_ibfk_1     | test         | kind       | FOREIGN KEY     |
+--------------------+-------------------+-----------------+--------------+------------+-----------------+
 
mysql> select * from KEY_COLUMN_USAGE WHERE CONSTRAINT_NAME='kind_ibfk_1'\G
*************************** 1. row ***************************
           CONSTRAINT_CATALOG: def
            CONSTRAINT_SCHEMA: test
              CONSTRAINT_NAME: kind_ibfk_1
                TABLE_CATALOG: def
                 TABLE_SCHEMA: test
                   TABLE_NAME: kind
                  COLUMN_NAME: id2
             ORDINAL_POSITION: 1
POSITION_IN_UNIQUE_CONSTRAINT: 1
      REFERENCED_TABLE_SCHEMA: test
        REFERENCED_TABLE_NAME: papa
       REFERENCED_COLUMN_NAME: id

mysql> SELECT concat(A.TABLE_SCHEMA,'/',A.TABLE_NAME,':',A.COLUMN_NAME,' -> ',A.REFERENCED_TABLE_SCHEMA,'/',A.REFERENCED_TABLE_NAME,':',A.REFERENCED_COLUMN_NAME) FK from KEY_COLUMN_USAGE A JOIN TABLE_CONSTRAINTS USING(CONSTRAINT_NAME) WHERE TABLE_CONSTRAINTS.CONSTRAINT_TYPE='FOREIGN KEY';
+-------------------------------+
| FK                            |
+-------------------------------+
| test/kind:id2 -> test/papa:id |
+-------------------------------+

Wenn sich jemand merkt, wofür die jeweiligen Werte der Type Spalte in 5.6.2 stehen, sind im Zugriff auf INNODB_SYS_FROREIG% mehr Informationen zu holen. Letzterer Ansatz hat nicht nur denVorteil auf MySQL 5.1.x und 5.5.x zu laufen, sondern auch FKs auf Tabellen zu entdecken, welche nicht InnoDB sind.



Viel Spaß
Erkan

DOAG 2011

| Keine Kommentare | Keine TrackBacks
Moin, morgen beginnt die DOAG 2011. Auf der werden einige Vorträge gehalten werden.
Zwei (1,2) von mir. 
Jene, welche sich dort aufhalten, werden gebeten aufzuschlagen.

Viel Spaß
Erkan :)

About Me

Aktuelle Kommentare

  • kero: Danke, besonders fuer Galera. weiter lesen
  • erkan: Ohh ahh Dahanke! :) weiter lesen
  • Matthias Klein: Moinsen, danke für die PDF's, hab meinen Chef schon auf weiter lesen
  • erkan: Uhh Ahh thx. Fixed. Bis 'nachher' weiter lesen
  • Henning Rohde: Moin! Danke für die Slides - in der URL für weiter lesen
  • erkan: Es gab zumindest mal einen Lenz, der das irgendwie noch weiter lesen
  • hartmut: Ja, auch bzr tut wieder ... wäre nur schön sowas weiter lesen
  • erkan: Hehe done :) Btw: http://linsenraum.de/erkules/2011/03/clt-vortragsfolien-lxc.html ;) weiter lesen
  • Toto: Ja, viel hype aus der ubuntu szene da es dort weiter lesen
  • erkan: Moinsen, ist nicht klar? War nicht klar? Hättest Du die weiter lesen

Aktuelle Assets

  • launchpad.png

Seiten