June 2018 - discuss - lists.mariadb.org

[Maria-discuss] MariaDB Developers Unconference in a few weeks!
by Otto Kekäläinen 09 Jun '18

09 Jun '18

Hello everybody! The next developers unconference will be in a few weeks: https://mariadb.org/2018-2-developers-unconference-in-finland/ There are still open slots so we encourage you to sign up now. https://www.meetup.com/MariaDB-Developers/events/249024232/ We have plenty of break-out rooms this time and there is space, so we also encourage you to suggest sessions/discussions you would like to have to ian(a)mariadb.org. Around mid-summer is a great time to visit Finland. The nights that don't get dark are worth experiencing! Getting to the venue in Tampere., Finlnd is also very easy. https://mariadb.org/travel-tips-to-tampere-finland/#why-visit Hope to see you there! - Otto

1 0

[Maria-discuss] Upgrade paths through more major versions
by Michal Schorm 06 Jun '18

06 Jun '18

Hello, MariaDB changed its release cycle to 1 major version / year. However the upgrades remained supported only from one major version to the very next. I see a raise of users (of RH products - RHEL and RHSCL mainly) that would like to jump several versions. They had an application build on, let's say, 5.5 (RHEL7 default) and would like to get the features from 10.2 (available in RH software collections - we provide plenty of versions this way). So far, they have to upgrade one by one 5.5->10.0->10.1->10.2; and solve the conflicts at each stage. Lately, we discontinued support fo 10.0 in RHSCL, which means, the upgrade path metioned above won't be as easy anymore. Also mysqldump can't be used for upgrade to 10.3, which is IMHO frequently used. For other RH products, there is an ongoing discussions, whether support all major releases or if to skip some. Which implies the questions about the upgrades through versions we wouldn't pack. However skipping several versions is IMHO quite normal for products with slow release cycle, like RHEL, so I'd expect other companies providing similar systems / products with slow release cycle to face the same problems. Are there any plans to extend the upgrade paths through more versions? Have you encountered simmilar needs of the users? -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

4 6

[Maria-discuss] Why MyISAM as default engine for system tables ?
by Julien Muchembled 06 Jun '18

06 Jun '18

Hello, A few weeks ago, we got the following fatal error when starting mariadb: [Note] Starting crash recovery... [Note] Crash recovery finished. [ERROR] mysqld: Table './mysql/db' is marked as crashed and should be repaired [Warning] Checking table: './mysql/db' [ERROR] mysql.db: 1 client is using or hasn't closed the table properly tch value count at row 1 [ERROR] Aborting Unfortunately, what led to this is unclear. We only rebooted the machine. Maybe a hw raid issue. We did a copy at that time. I tried recently if it could be repaired but I don't have the a fatal error anymore. We also don't know why system tables were touched during the reboot. Anyway, given the description of Aria ("Crash-safe tables with MyISAM heritage"), I understand that MyISAM is not crash-safe. Then, why keep using MyISAM as default engine for system tables, when MariaDB has Aria or InnoDB ? Not sure a crash-safe engine would have helped in the above case (there's no miracle for data corruption). But we'd like at least that all our mariadb setups are crash-safe (e.g. power cuts) and we use InnoDB partly for that. And I don't know if a InnoDB DB could be always recoverable if the 'mysql' DB is lost but we don't want to do manually (and learn how to) what the machine can do automatically. Julien

6 8