Agrégateur de flux

FromDual has the pleasure to announce the release of the new version 1.2.0 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

The new MyEnv can be downloaded here.

In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

Upgrade from 1.1.x to 1.2.0 # cd ${HOME}/product # tar xf /download/myenv-1.2.0.tar.gz # rm -f myenv # ln -s myenv-1.2.0 myenv

If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
Changes in MyEnv 1.2.0 MyEnv

• Some minor fixes on init script.
• Introduction of states production, quality, testing and development.
• Colored prompt added for stage production databases.
• All /tmp/*sock moved to /var/run/mysqld.
• up output prepared for bind-address awareness.
• lsb_release dummy implemented.

MyEnv Installer

• Advice for 2 sudo commands in row was wrong.
• Port conflict resolution more verbose.
• Init script replacement check added. Replace init script is distribution aware and auto executable.
• Installer made mode modular and prepared for automatization.
• Installer allows now to run as other user than mysql.
• Bugs in preparing myenv.conf fixed and instance name removed.
• Install routine made more distribution aware.

MyEnv Utilities

• Split partition (split_partition.php) improved.
• Fix of DROP PARTITION (drop_partition.php) was executed in wrong order (new before old).
• Alter Engine script rewritten into PHP (alter_engine.php).
• Alter Engine script handles ROW_FORMAT=FIXED problem correctly now.
• Alter Engine script handles too large Primary Key better.
• Alter Engine script recognizes tables with AUTO_INCREMENT column not at 1st position.
• Purge Binary Log rewritten into PHP (purge_binary_log.php).
• compare_status_files.pl added to compare output of 2 SHOW GLOBAL STATUS.

For subscriptions of commercial use of MyEnv please get in contact with us.

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgraderelease

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationtestingupgrade

FromDual has the pleasure to announce the release of the new version 1.2.0 of its popular MySQL, Galera Cluster, MariaDB and Percona Server multi-instance environment MyEnv.

The new MyEnv can be downloaded here.

In the inconceivable case that you find a bug in the MyEnv please report it to our bug tracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

Upgrade from 1.1.x to 1.2.0 # cd ${HOME}/product # tar xf /download/myenv-1.2.0.tar.gz # rm -f myenv # ln -s myenv-1.2.0 myenv

If you are using plug-ins for showMyEnvStatus create all the links in the new directory structure:

cd ${HOME}/product/myenv ln -s ../../utl/oem_agent.php plg/showMyEnvStatus/
Changes in MyEnv 1.2.0 MyEnv

• Some minor fixes on init script.
• Introduction of states production, quality, testing and development.
• Colored prompt added for stage production databases.
• All /tmp/*sock moved to /var/run/mysqld.
• up output prepared for bind-address awareness.
• lsb_release dummy implemented.

MyEnv Installer

• Advice for 2 sudo commands in row was wrong.
• Port conflict resolution more verbose.
• Init script replacement check added. Replace init script is distribution aware and auto executable.
• Installer made mode modular and prepared for automatization.
• Installer allows now to run as other user than mysql.
• Bugs in preparing myenv.conf fixed and instance name removed.
• Install routine made more distribution aware.

MyEnv Utilities

• Split partition (split_partition.php) improved.
• Fix of DROP PARTITION (drop_partition.php) was executed in wrong order (new before old).
• Alter Engine script rewritten into PHP (alter_engine.php).
• Alter Engine script handles ROW_FORMAT=FIXED problem correctly now.
• Alter Engine script handles too large Primary Key better.
• Alter Engine script recognizes tables with AUTO_INCREMENT column not at 1st position.
• Purge Binary Log rewritten into PHP (purge_binary_log.php).
• compare_status_files.pl added to compare output of 2 SHOW GLOBAL STATUS.

For subscriptions of commercial use of MyEnv please get in contact with us.

Taxonomy upgrade extras: logginggaleraclusterconflictdeadlockerror logerror

We typically suggest our customers to use our MySQL/Galera Cluster my.cnf configuration template to avoid MySQL configuration and performance problems.

And we are paranoid as well. Thus we enable all useful logging:

wsrep_log_conflicts = 1

But this has also some consequences of more visibility...

If you monitor carefully your Galera Cluster for example with the FromDual Performance Monitor for MySQL and MariaDB, you might probably see some strange values increasing from time to time:

mysql< SHOW GLOBAL STATUS LIKE 'wsrep_local_%r_s'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | wsrep_local_cert_failures | 42 | | wsrep_local_bf_aborts | 13 | +---------------------------+-------+

Those values are indicators that some transactions (Galera write sets) did to not succeed and were aborted by Galera. In this case the paranoid logging helps to find, what exactly was aborted and possibly helps to find out, if this can or should be fixed:

150410 1:44:18 [Note] WSREP: cluster conflict due to certification failure for threads: 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: executing, conflict: cert failure, seqno: 30399304 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(NOW()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** Priority TRANSACTION: TRANSACTION 464359568, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 1 lock struct(s), heap size 360, 0 row lock(s) MySQL thread id 4, OS thread handle 0x7f1c0916c700, query id 8190690 Update_rows_log_event::find_row(30399302) *** Victim TRANSACTION: TRANSACTION 464359562, ACTIVE 0 sec mysql tables in use 1, locked 1 2 lock struct(s), heap size 360, 1 row lock(s), undo log entries 1 MySQL thread id 151856, OS thread handle 0x7f1c09091700, query id 8190614 172.20.100.11 sam_angiz query end UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5' *** WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 835205 page no 3 n bits 72 index `PRIMARY` of table `fromdual`.`login` trx table locks 1 total table locks 2 trx id 464359562 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0 150410 1:44:18 [Note] WSREP: cluster conflict due to high priority abort for threads: 150410 1:44:18 [Note] WSREP: Winning thread: THD: 4, mode: applier, state: executing, conflict: no conflict, seqno: 30399302 SQL: (null) 150410 1:44:18 [Note] WSREP: Victim thread: THD: 151856, mode: local, state: committing, conflict: no conflict, seqno: -1 SQL: UPDATE login SET lTsexpire = UNIX_TIMESTAMP(now()) + lTimeout WHERE lSessionId = 'va3ta7besku82k56ncv3bnhlj5'

In the above Galera conflict 2 login transactions where running at the same time. They both come with the same Session ID and want to update the expiry timestamp. Now how to solve or fix this:

• First check, if this table has a Primary Key (tables without a PK causes full table scans which can last for long time, increasing the chance for conflicts).
• Second check, if there is a (UNIQUE?) index on lSessionId. A missing index leads to full table scans which increases the chance for conflicts.
• Third check WHY 2 logins from the same Session ID can arrive at the same time (within 1 second) on 2 different Galera nodes (Ajax requests, etc...). Try to avoid such situations.

Taxonomy upgrade extras: galeravmwaresnapshot

From time to time we see at Galera Cluster customer engagements the following, for me scary, warning in the MySQL error log:

[Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check

We mostly see this in VMware set-ups. Some further enquiry with the Galera developers did not give a satisfying answer:

This can be seen on bare metal as well - with poorly configured mysqld, O/S, or simply being overloaded. All it means is that this thread could not get CPU time for 7.1 seconds. You can imagine that access to resources in virtual machines is even harder (especially I/O) than on bare metal, so you will see this in virtual machines more often.

This is not a Galera specific issue (it just reports being stuck, other mysqld threads are equally stuck) so there is no configuration options for that. You simply must make sure that your system and mysqld are properly configured, that there is enough RAM (buffer pool not over provisioned), that there is swap, that there are proper I/O drivers installed on guest and so on.

Basically, Galera runs in virtual machines as well as well virtual machines approximates bare metal.

We were still suspecting that this is somehow VMware related. This week we had the chance to investigate... At 01:36 am node Galera2 lost connection to the Cluster and became NON-PRIMARY. This is basically a bad sign:

150401 1:36:15 [Warning] WSREP: last inactive check more than PT1.5S ago (PT5.08325S), skipping check 150401 1:36:15 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.42.2:4567 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,30) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: view(view_id(NON_PRIM,09c6b2f2,31) memb { 09c6b2f2,0 } joined { } left { } partitioned { ce6bf2e1,0 d1f9bee0,0 }) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 26304132) 150401 1:36:16 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1 150401 1:36:16 [Note] WSREP: Flow-control interval: [16, 16] 150401 1:36:16 [Note] WSREP: Received NON-PRIMARY. 150401 1:36:16 [Warning] WSREP: Send action {(nil), 328, TORDERED} returned -107 (Transport endpoint is not connected) 150401 1:36:16 [Note] WSREP: New cluster view: global state: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:26304132, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3 150401 1:36:17 [Note] WSREP: (09c6b2f2, 'tcp://0.0.0.0:4567') reconnecting to d1f9bee0 (tcp://192.168.42.1:4567), attempt 0

I suspected, after some investigation with the FromDual Performance Monitor for MySQL and MariaDB, that the database backup (mysqldump) could be the reason. It was not. But the customer explained, that after the database backup they do a VMware snapshot.

And when we compared our problem with the backup log file:

2015/04/01 01:35:08 [3] backup.fromdual.com: Creating a snapshot of galera3 2015/04/01 01:35:16 [3] backup.fromdual.com: Created a snapshot of galera3 2015/04/01 01:35:23 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015/04/01 01:36:10 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015/04/01 01:36:10 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3

we can see that our problem pretty much started with the end of the WMware snapshot (01:36:10 + 5.08 = 1:36:15). By the way: For such kind of investigations it is always good to have a ntp daemon for time synchronization running. Otherwise problem investigation becomes much harder...

Some more and deeper investigation shows that we loose from time to time nodes during VMware snapshots (galera3). But they recover quickly because they can do an IST. In worst case we can loose 2 nodes and then the whole Galera Cluster has gone.

192.168.42.3 / node Galera3 2015-04-10 01:44:00 [3] backup.fromdual.com: Creating a snapshot of galera3 2015-04-10 01:44:08 [3] backup.fromdual.com: Created a snapshot of galera3 2015-04-10 01:44:15 [3] backup.fromdual.com: galera3: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:45:39 [3] backup.fromdual.com: galera3: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:45:39 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera3
150410 1:44:07 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:44:07 [Warning] WSREP: last inactive check more than PT1.5S ago (PT7.06159S), skipping check 150410 1:44:08 [Note] WSREP: Received NON-PRIMARY. 150410 1:44:10 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 30399299) 150410 1:44:11 [Warning] WSREP: Gap in state sequence. Need state transfer. 150410 1:44:11 [Note] WSREP: Prepared IST receiver, listening at: tcp://galera3:4568 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:11 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 30399309) 150410 1:44:11 [Note] WSREP: Requesting state transfer: success, donor: 2 150410 1:44:11 [Note] WSREP: 2.0 (galera2): State transfer to 0.0 (galera3) complete. 150410 1:44:11 [Note] WSREP: Member 2.0 (galera2) synced with group. 150410 1:44:11 [Note] WSREP: Receiving IST: 8 writesets, seqnos 30399291-30399299 150410 1:44:11 [Note] WSREP: IST received: dcca768c-b5ad-11e3-bbc0-fb576fb3c451:30399299 150410 1:44:11 [Note] WSREP: 0.0 (galera3): State transfer from 2.0 (galera2) complete. 150410 1:44:11 [Note] WSREP: Shifting JOINER -> JOINED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) synced with group. 150410 1:44:11 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 30399309) 150410 1:44:11 [Note] WSREP: Synchronized with group, ready for connections 150410 1:44:13 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:42 [Warning] WSREP: last inactive check more than PT1.5S ago (PT2.47388S), skipping check 150410 1:45:43 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 tcp://galera2:4567 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:45:44 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to c9d964d3 (tcp://galera2:4567), attempt 0 150410 1:45:48 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:31 [Note] WSREP: (158f71de, 'tcp://0.0.0.0:4567') turning message relay requesting off
192.168.42.1 / node Galera1 2015-04-10 01:47:24 [3] backup.fromdual.com: Creating a snapshot of galera1 2015-04-10 01:47:29 [3] backup.fromdual.com: Created a snapshot of galera1 2015-04-10 01:47:40 [3] backup.fromdual.com: galera1: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 01:48:43 [3] backup.fromdual.com: galera1: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 01:48:44 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera1 150410 1:44:02 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:04 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:12 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:45:43 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:27 [Warning] WSREP: last inactive check more than PT1.5S ago (PT3.66452S), skipping check 150410 1:47:27 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:47:30 [Note] WSREP: (54de92f8, 'tcp://0.0.0.0:4567') turning message relay requesting off
192.168.42.2 / node Galera2 2015-04-10 02:09:55 [3] backup.fromdual.com: Creating a snapshot of galera2 2015-04-10 02:09:58 [3] backup.fromdual.com: Created a snapshot of galera2 2015-04-10 02:10:05 [3] backup.fromdual.com: galera2: backup the changed blocks of disk 'Festplatte 1' using NBD transport 2015-04-10 02:10:53 [3] backup.fromdual.com: galera2: saving the Change Block Tracking's reference for disk 'Festplatte 1' 2015-04-10 02:10:54 [3] backup.fromdual.com: Removing Arkeia's snapshot of galera2
150410 1:44:02 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:44:03 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:44:08 [Warning] WSREP: discarding established (time wait) 158f71de (tcp://192.168.42.3:4567) 150410 1:44:11 [Note] WSREP: Member 0.0 (galera3) requested state transfer from '*any*'. Selected 2.0 (galera2)(SYNCED) as donor. 150410 1:44:13 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:45:43 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera3:4567 150410 1:45:44 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 158f71de (tcp://galera3:4567), attempt 0 150410 1:45:48 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 1:47:26 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://galera1:4567 150410 1:47:27 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') reconnecting to 54de92f8 (tcp://galera1:4567), attempt 0 150410 1:47:30 [Note] WSREP: (c9d964d3, 'tcp://0.0.0.0:4567') turning message relay requesting off 150410 2:09:57 [Warning] WSREP: last inactive check more than PT1.5S ago (PT1.83618S), skipping check

The backups are done with the 2 options:

• Change Block Tracking (CBT) (Arkeia, VMware) and
• Quiesce Guest File System (Arkeia, VMware)

enabled.

Possibly this is the reason and one should disable those features in combination with Galera. Further investigation is going on. In worst case VMware snapshotting with Galera should be avoided.

Im April und Mai 2015 bieten wir wieder viele interessante und spannende Kurse rund um MySQL an.

Falls Sie Interesse haben, an diesen Schulungen teilzunehmen, sollten Sie Sich schnell anmelden, um Sich Ihren Platz zu sichern. Es sind nur noch wenige Plätze vorhanden.

Folgende Kurse zum Thema MySQL und Galera Cluster finden im April und Mai statt:

MySQL für Profis vom 20. - 24. April 2015 in der Heinlein Akademie in Berlin. Hier anmelden.

Galera Cluster für MySQL vom 05. - 06. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

MySQL für Fortgeschrittene vom 18. - 22. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL/MariaDB Schulung.

Taxonomy upgrade extras: mysqlmariadbgaleraschulungtraining

Im April und Mai 2015 bieten wir wieder viele interessante und spannende Kurse rund um MySQL an.

Falls Sie Interesse haben, an diesen Schulungen teilzunehmen, sollten Sie Sich schnell anmelden, um Sich Ihren Platz zu sichern. Es sind nur noch wenige Plätze vorhanden.

Folgende Kurse zum Thema MySQL und Galera Cluster finden im April und Mai statt:

MySQL für Profis vom 20. - 24. April 2015 in der Heinlein Akademie in Berlin. Hier anmelden.

Galera Cluster für MySQL vom 05. - 06. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

MySQL für Fortgeschrittene vom 18. - 22. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL/MariaDB Schulung.

Taxonomy upgrade extras: mysqlmariadbgaleraschulungtraining

Taxonomy upgrade extras: mysqlmariadbgaleraschulungtraining

Im April und Mai 2015 bieten wir wieder viele interessante und spannende Kurse rund um MySQL an.

Falls Sie Interesse haben, an diesen Schulungen teilzunehmen, sollten Sie Sich schnell anmelden, um Sich Ihren Platz zu sichern. Es sind nur noch wenige Plätze vorhanden.

Folgende Kurse zum Thema MySQL und Galera Cluster finden im April und Mai statt:

MySQL für Profis vom 20. - 24. April 2015 in der Heinlein Akademie in Berlin. Hier anmelden.

Galera Cluster für MySQL vom 05. - 06. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

MySQL für Fortgeschrittene vom 18. - 22. Mai 2015 im LinuxHotel in Essen. Hier anmelden.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL/MariaDB Schulung.

Call for Papers für IT-Tage mit dem Schwerpunkt Datenbanken vom 14. bis 18. Dezember 2015 in Frankfurt ist eröffnet.

Die Organisatoren würden sich über zahlreiche Vortrags-Einreichungen freuen...

Die IT-Tage mit dem Schwerpunkt Datenbanken finden im Rahmen der Reihe "Informatik Aktuell – Wissen kompakt" zentral in Frankfurt am Main / Messe statt.

Call for Papers für IT-Tage mit dem Schwerpunkt Datenbanken vom 14. bis 18. Dezember 2015 in Frankfurt ist eröffnet.

Die Organisatoren würden sich über zahlreiche Vortrags-Einreichungen freuen...

Die IT-Tage mit dem Schwerpunkt Datenbanken finden im Rahmen der Reihe "Informatik Aktuell – Wissen kompakt" zentral in Frankfurt am Main / Messe statt.

Call for Papers für IT-Tage mit dem Schwerpunkt Datenbanken vom 14. bis 18. Dezember 2015 in Frankfurt ist eröffnet.

Die Organisatoren würden sich über zahlreiche Vortrags-Einreichungen freuen...

Die IT-Tage mit dem Schwerpunkt Datenbanken finden im Rahmen der Reihe "Informatik Aktuell – Wissen kompakt" zentral in Frankfurt am Main / Messe statt.

Unsere Präsentation von der CeBit 2015: MySQL Performance Tuning für Entwickler kann jetzt heruntergeladen werden.

Inhalt: Datenbank Performance, Profiling, General Query Log, des Admins Bazooka, Slow Query Log, Query Analyzer, Query Execution Plan, EXPLAIN, Indexieren, ...

Taxonomy upgrade extras: general query logPerformance Tuningentwickler

Unsere Präsentation von der CeBit 2015: MySQL Performance Tuning für Entwickler kann jetzt heruntergeladen werden.

Inhalt: Datenbank Performance, Profiling, General Query Log, des Admins Bazooka, Slow Query Log, Query Analyzer, Query Execution Plan, EXPLAIN, Indexieren, ...

Unsere Präsentation von der CeBit 2015: MySQL Performance Tuning für Entwickler kann jetzt heruntergeladen werden.

Inhalt: Datenbank Performance, Profiling, General Query Log, des Admins Bazooka, Slow Query Log, Query Analyzer, Query Execution Plan, EXPLAIN, Indexieren, ...

Taxonomy upgrade extras: partitionrenameDDL

Before I forget it and have to search again here a short note about how to rename a MySQL Partition:

My dream:

ALTER TABLE history RENAME PARTITION p2015_kw10 INTO p2015_kw09;
In reality: ALTER TABLE history REORGANIZE PARTITION p2015_kw10 INTO ( PARTITION p2015_kw09 VALUES LESS THAN (UNIX_TIMESTAMP('2015-03-02 00:00:00')) );

Caution: REORGANIZE PARTITION causes a full copy of the whole partition!

Hint: I assume it would be very easy for MySQL or MariaDB to make this DDL command an in-place operation...

MySQL Partitioning was introduced in MySQL 5.1.

FromDual is pleased to announce the release of a new version 1.0.0 of the Nagios and Icinga plug-ins for MySQL, MariaDB, Percona Server and Galera Cluster.

Any information about the changes and the new functions of the Nagios and Icinga plug-ins you can find here.

If you have any problems with the new version you can reach us by e-mail at: contact@fromdual.com or by phone on +41 44 500 58 20.

Your FromDual Team

Taxonomy upgrade extras: nagiosicingaplug-inmysqlmariadbpercona serverGalera Clusterrelease

FromDual is pleased to announce the release of a new version 1.0.0 of the Nagios and Icinga plug-ins for MySQL, MariaDB, Percona Server and Galera Cluster.

Any information about the changes and the new functions of the Nagios and Icinga plug-ins you can find here.

If you have any problems with the new version you can reach us by e-mail at: contact@fromdual.com or by phone on +41 44 500 58 20.

Your FromDual Team

Taxonomy upgrade extras: nagiosicingaplug-inmysqlmariadbpercona serverGalera Clusterrelease

Taxonomy upgrade extras: nagiosicingaplug-inmysqlmariadbpercona serverGalera Clusterrelease

FromDual is pleased to announce the release of a new version 1.0.0 of the Nagios and Icinga plug-ins for MySQL, MariaDB, Percona Server and Galera Cluster.

Any information about the changes and the new functions of the Nagios and Icinga plug-ins you can find here.

If you have any problems with the new version you can reach us by e-mail at: contact@fromdual.com or by phone on +41 44 940 24 82.

Your FromDual Team

Aus dem Hause Oracle gibt es zwei kostenfreie Datenbank-Systeme: Oracle XE und MySQL. Für alle, die mehr darüber wissen wollen als nur die Namen, stellt die DOAG (Deutsche Oracle-Anwendergruppe e.V.) sie in einem Duell einander gegenüber - mit Kurzvorträgen, Diskussionen und "Live Hacking". Unser CTO Oliver Sennhauser wird dabei die MySQL-Seite vertreten.

Neben diesen fachlichen Inhalten werden natürlich auch das leibliche Wohl und das Knüpfen von Kontakte nicht zu kurz kommen. Geben Sie Ihre Erfahrungen weiter, und profitieren Sie von denen der anderen!

Die Veranstaltung findet vom 5. zum 6. Februar im Derag Livinghotel Maximilian in Nürnberg statt, weitere Details und die Anmelde-Möglichkeit finden Sie hier.

Auf spannende und ereignisreiche Stunden mit Ihnen freut sich unser CTO Oliver Sennhauser.

Taxonomy upgrade extras: doagmysqlOracle

Aus dem Hause Oracle gibt es zwei kostenfreie Datenbank-Systeme: Oracle XE und MySQL. Für alle, die mehr darüber wissen wollen als nur die Namen, stellt die DOAG (Deutsche Oracle-Anwendergruppe e.V.) sie in einem Duell einander gegenüber - mit Kurzvorträgen, Diskussionen und "Live Hacking". Unser CTO Oliver Sennhauser wird dabei die MySQL-Seite vertreten.

Neben diesen fachlichen Inhalten werden natürlich auch das leibliche Wohl und das Knüpfen von Kontakte nicht zu kurz kommen. Geben Sie Ihre Erfahrungen weiter, und profitieren Sie von denen der anderen!

Die Veranstaltung findet vom 5. zum 6. Februar im Derag Livinghotel Maximilian in Nürnberg statt, weitere Details und die Anmelde-Möglichkeit finden Sie hier.

Auf spannende und ereignisreiche Stunden mit Ihnen freut sich unser CTO Oliver Sennhauser.

Taxonomy upgrade extras: doagmysqlOracle

Taxonomy upgrade extras: doagmysqlOracle

Aus dem Hause Oracle gibt es zwei kostenfreie Datenbank-Systeme: Oracle XE und MySQL. Für alle, die mehr darüber wissen wollen als nur die Namen, stellt die DOAG (Deutsche Oracle-Anwendergruppe e.V.) sie in einem Duell einander gegenüber - mit Kurzvorträgen, Diskussionen und "Live Hacking". Unser CTO Oliver Sennhauser wird dabei die MySQL-Seite vertreten.

Neben diesen fachlichen Inhalten werden natürlich auch das leibliche Wohl und das Knüpfen von Kontakte nicht zu kurz kommen. Geben Sie Ihre Erfahrungen weiter, und profitieren Sie von denen der anderen!

Die Veranstaltung findet vom 5. zum 6. Februar im Derag Livinghotel Maximilian in Nürnberg statt, weitere Details und die Anmelde-Möglichkeit finden Sie hier.

Auf spannende und ereignisreiche Stunden mit Ihnen freut sich unser CTO Oliver Sennhauser.