Home News Feeds Planet MySQL

Newsfeeds

Planet MySQL
Planet MySQL - https://planet.mysql.com

  • Donkey System
    Donkey system is a fully automatic MySQL database change system. It gives a great help both to the release of the business and the company’s automated operation and maintenance. Donkey.pptxDonkey_intro.pdf

  • Meltdown vs storage
    tl;dr - sysbench fileio throughput for ext4 drops by more than 20% from Linux 4.8 to 4.13I shared results from sysbench with a cached database to show a small impact from the Meltdown patch in Ubuntu 16.04. Then I repeated the test for an IO-bound configuration using a 200mb buffer pool for InnoDB and database that is ~1.5gb.The results for read-only tests looked similar to what I saw previously so I won't share them. The results for write-heavy tests were odd as QPS for the kernel without the patch (4.8.0-36) were much better than for the kernel with the patch (4.13.0-26).The next step was to use sysbench fileio to determine whether storage performance was OK and it was similar for 4.8 and 4.13 with read-only and write-only tests. But throughput with 4.8 was better than 4.13 for a mixed test that does reads and writes.ConfigurationI used a NUC7i5bnh server with a Samsung 960 EVO SSD that uses NVMe. The OS is Ubuntu 16.04 with the HWE kernels -- either 4.13.0-26 that has the Meltdown fix or 4.8.0-36 that does not. For the 4.13 kernel I repeat the test with PTI enabled and disabled. The test uses sysbench with one 2gb file, O_DIRECT and 4 client threads. The server has 2 cores and 4 HW threads. The filesystem is ext4.I used these command lines for sysbench:sysbench fileio --file-num=1 --file-test-mode=rndrw --file-extra-flags=direct \    --max-requests=0 --num-threads=4 --max-time=60 preparesysbench fileio --file-num=1 --file-test-mode=rndrw --file-extra-flags=direct \    --max-requests=0 --num-threads=4 --max-time=60 runAnd I see this:cat /sys/block/nvme0n1/queue/write_cachewrite backResultsThe next step was to understand the impact of the filesystem mount options. I used ext4 for these tests and don't have much experience with it. The table has the throughput in MB/s from sysbench fileio that does reads and writes. I noticed a few things: Throughput is much worse with the nobarrier mount option. I don't know whether this is expected. There is a small difference in performance from enabling the Meltdown fix - about 3% There is a big difference in performance between the 4.8 and 4.13 kernels, whether or not PTI is enabled for the 4.13 kernel. I get about 25% more throughput with the 4.8 kernel. 4.13    4.13    4.8    mount optionspti=on  pti=off no-pti100     104     137     nobarrier,data=ordered,discard,noauto,dioread_nolock 93     119     128     nobarrier,data=ordered,discard,noauto226     235     275     data=ordered,discard,noauto233     239     299     data=ordered,discard,noauto,dioread_nolockIs it the kernel?I am curious about what happened between 4.8 and 4.13 to explain the 25% loss of IO throughput.I have another set of Intel NUC servers that use Ubuntu 16.04 without the HWE kernels -- 4.4.0-109 with the Meltdown fix and 4.4.0-38 without the Meltdown fix. These servers still use XFS. I get ~2% more throughput with the 4.4.0-38 kernel than the 4.4.0-109 kernel (whether or not PTI is enabled).The loss in sysbench fileio throughput does not reproduce for XFS. The filesystem mount options are "noatime,nodiratime,discard,noauto" and tests were run with /sys/block/nvme0n1/queue/write_cache set to write back and write through. The table below has MB/s of IO throughput.4.13    4.13    4.8pti=on  pti=off no-pti225     229     232     write_cache="write back"125     168     138     write_cache="write through"More debuggingThis is vmstat output from the sysbench test and the values for wa are over 40 for the 4.13 kernel but less than 10 for the 4.8 kernel. The ratio of cs per IO operation is similar for 4.13 and 4.8.# vmstat from 4.13 with pti=offprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 0  4      0 15065620 299600 830564    0    0 64768 43940 7071 21629  1  6 42 51  0 0  4      0 15065000 300168 830512    0    0 67728 45972 7312 22816  1  3 44 52  0 2  2      0 15064380 300752 830564    0    0 69856 47516 7584 23657  1  5 43 51  0 0  2      0 15063884 301288 830524    0    0 64688 43924 7003 21745  0  4 43 52  0# vmstat from 4.8 with pti=onprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 0  4      0 14998364 384536 818532    0    0 142080 96484 15538 38791  1  6  9 84  0 0  4      0 14997868 385132 818248    0    0 144096 97788 15828 39576  1  7 10 83  0 1  4      0 14997248 385704 818488    0    0 151360 102796 16533 41417  2  9  9 81  0 0  4      0 14997124 385704 818660    0    0 140240 95140 15301 38219  1  7 11 82  0

  • FOSDEM MySQL Community Dinner – Friday 2 Feb 2018 – Tickets Now Available!
    FOSDEM is back in town, folks, and as usual, there will there be a MySQL and Friends Devroom. At this point, we can’t really remember what came first, was it the annual dinner or the devroom? Our memories of the past few years are particularly hazy on that…  Can’t imagine why. Following a great tradition of dining together in style with members from all over the community, we have rented a by now familiar private space at ICAB, more detailed directions below. A couple of things changed compared to the last couple of years. The community dinner will take place on Friday night 2 February, following the Pre FOSDEM MySQL Day, both in the same location. Book your tickets now!!! The listed ticket price includes a selection of Belgian Speciality Beers and food, which will be typical Belgian style (no ‘Italian’ Pizza!) If you have any dietary requirements (vegetarian, vegan, gluten-free,…) please let us know ahead of time when buying the ticket as we need to inform the caterer who will make the necessary accommodations for you. We’re looking forward to meeting you all again at Fosdem and the Community Dinner. See you then! Party-Squad – Dimitri Vanoverbeke, Tom De Cooman, Liz van Dijk, (Kenny Gryp) Sponsors Once again, we want to thank our generous sponsors, whose help makes this affordable at such a great price. Community Sponsors: Other Sponsors: ICAB Brussels – Business and Technology Incubator Wondering how to get there? The venue itself is located very close to the VUB. A map is displayed below to help you plan your route. The total distance from the heart of Brussels, Grand Place, is about 20 minutes by public transport, along the route of metro line 5 (closest stop: Petillon). Be sure to use Google/Apple/Your Preferred Maps to determine the best way to get there, though as both tram and bus lines are also an option.

  • Shinguz: Advanced MySQL and MariaDB training in Cologne 2018
    End of February, from February 26 to March 2 (5 days), FromDual offers an additional training for DBAs and DevOps: our most visited Advanced MySQL and MariaDB training. This training is hold in the training facilities of the FromDual training partner GFU Cyrus GmbH in Cologne-Deutz (Germany). There are already enough registrations so it is certain the training will take place. But there are still free places for at least 3 additional participants. The training is in German. You can find the training of this 5-day MySQL/MariaDB training here. If you have any question please do not hesitate to contact us. Taxonomy upgrade extras:  training advanced cologne

  • Shinguz: Oracle releases MySQL security vulnerability fixes 2018-01
    As in every quarter of the year Oracle has released yesterday its recommendation for the MySQL security updates. This is called, in Oracle terminology, Critical Patch Update (CPU) Advisory. This CPU is published for all Oracle products. But FromDual is only interested in MySQL related topics. So let us concentrate on those. This time 25 fixes with a maximum score of 8.1 (out of 10.0) were published. 6 of theses 25 vulnerabilities are exploitable remotely over the network without authentication (no user credentials required)! The following MySQL products are affected: MySQL Enterprise Monitor (3.3.6.3293 and before, 3.4.4.4226 and before, 4.0.0.5135 and before) MySQL Connector/Net (6.9.9. and before, 6.10.4 and before) MySQL Connector/ODBC (5.3.9. and before) MySQL Server (5.5.58 and before, 5.6.38 and before, 5.7.19 and before) It is recommended to upgrade your MySQL products to close the security vulnerabilities. FromDual upgrade decision aid Because such security updates are published quarterly and some of our customers have dozens to hundreds of MySQL installations this would end up in a never ending story where you are continuously upgrading MySQL database servers and other products. This led to idea to create an upgrade decision aid to decide if you have to upgrade to this CPU or not. The following questions can be asked: How exposed is your database? Databases can be located in various network segments. It is not recommended to expose databases directly to the internet. Databases are either installed in demilitarized zones (DMZ) with no direct access from the internet or in the companies private network (only company employees should be able to access the database) or even specialized secure networks (only a limited number of specific employees can access this network). How critical are your data? Some data are more interesting or critical, some data are less interesting or critical. Interesting data are: User data (user name and password), customer data (profiles, preferences, etc.), financial data (credit cards) and health care data (medical data). Systems containing such data are more critical than others. You can also ask: How sever is it if such data leak? How broad is the user base able to access the database? How many employees do you have in your company? How many contractors do you have in your company? How many employees have physical access to the database server? How good is the mood of those people? How good are the user credentials to protect your database? Do you have shared passwords or no passwords at all? Do you have an account management (expiring old accounts, rotate passwords from time to time)? How much do you trust your users? Do you trust all your employees? Do you trust only admins? Or do you not even trust your admins? How severe are the security vulnerabilities? You can define a threshold of severity of the vulnerabilities above you want to take actions. According to your criticality you can take actions for example as follows: Greater or equal than 7.5 if you have less critical data. Greater or equal than 6.0 if you have critical data. Can the vulnerability be use from remote (over the network) and does it need a user authentication to exploit the vulnerability? What products (MySQL Enterprise Monitor, MySQL Server, MySQL Connectors) and what modules (Apache/Tomcat, .Net Connector, Partitioning, Stored Procedures, InnoDB, DDL, GIS, Optimizer, ODBC, Replication, DML, Performance Schema) are affected? Depending on your readiness to take a risk you get now answers to decide if you have to take actions or not. Some examples Situation: Your database is exposed directly to the internet or you forgot to install some firewall rules to protect your MySQL port.Analysis: You are probably affected by CVE-2018-2696 and CVE-2017-3737 (score 5.9 and 7.5). So you passed the threshold for non-critical data (7.5) and nearly passed the threshold for critical data (6.0). These vulnerabilities allow attacks over the network without user authentication.Action: Immediate upgrade is recommended. Mid-term action: Install firewall rules to protect your MySQL to avoid access from remote and/or do not expose databases directly to the internet. Situation: Your database is located in the intranet zone. You have slack user/password policies and you have many employees and also many contractors from foreign countries working on various projects. And you have very sensitive/interesting financial data stored in your database.Analysis: Many people, not all of them are really trusted, have network access to the database. It is quite possible that passwords have been shared or people have passwords for projects they are not working for any more. You are affected by nearly all of the vulnerabilities (network).Action: You should plan an upgrade soon. Mid-term action: Try to restrict access to the databases and implement some password policy rules (no shared passwords, password expiration, account locking etc.). Situation: Your highly critical databases are located in a specially secured network and only applications, Linux admins and DBAs have access to this network. And you completely trust those people.Analysis: Your threshold is 6.0 and (unauthenticated) attack over the network is not possible. There are some vulnerabilities of which you are affected but the database is only accessed by an application. So those vulnerabilities cannot be exploited easily.Action: You possibly can ignore this CPU for the MySQL database this time. But you have a vulnerability in the .Net Connector (Connector/Net). If an attacker exploits the vulnerability on the Connector he possibly can get access to the data. So you have to upgrade the Connector of your application accessing the database. If you follow the ideas of this aid you will probably have one or two upgrades a year. And this you should do anyway just to stay up to date... See also Common Vulnerability Scoring System Version 3.0 Calculator. Taxonomy upgrade extras:  cpu security mysql upgrade

Who's Online
We have 18 guests online