Software-update: MariaDB 10.9.2

MariaDB logo (79 pix)MariaDB is ontstaan als fork van MySQL, nadat dit door Oracle werd overgenomen. Voor een overzicht van de verschillen tussen MariaDB en MySQL kun je op deze en deze pagina's terecht. MariaDB is een krachtige opensourcedatabaseserver, die vooral populair is als website- en forumdatabase. De ontwikkelaars hebben versie versies 10.9.2, de eerste stabiele uitgave uit de 10.9-serie, en 10.10.1 uitgebracht. Die laatste wordt nog als release candidate aangeboden. De belangrijkste veranderingen en verbeteringen die in versie 10.9.2 zijn aangebracht zijn hieronder voor je op een rijtje gezet:

InnoDB Replication
  • ER_SLAVE_INCIDENT error is specified now on slave to be seen with SHOW-SLAVE-STATUS (MDEV-21087)
  • INCIDENT_EVENT is no longer binlogged when a being logged transaction can be safely rolledback (MDEV-21443)
  • sequences related row-format events are made to correspond to binlog_row_image (MDEV-28487)
  • Possible reason of FLUSH BINARY LOGS hang is eliminated (MDEV-28948)
  • Fix out-of-order gtid error in the circular semisync setup (MDEV-28609)
Galera
  • Possible to write/update with read_only=ON and not a SUPER privilege (MDEV-28546)
  • Node crashes with Transport endpoint is not connected mysqld got signal 6 (MDEV-25068)
  • Galera4 not able to report proper wsrep_incoming_addresses (MDEV-20627)
  • Galera should replicate nextval()-related changes in sequences with INCREMENT <> 0, at least NOCACHE ones with engine=InnoDB (MDEV-27862)
  • Add support for OpenSSL 3.0 in Galera (MDEV-25949)
Optimizer
  • Server crash in JOIN_CACHE::free or in copy_fields (MDEV-23809)
    • Queries that use DISTINCT and an always-constant function like COLLATION(aggegate_func(...)) could cause a server crash. Note that COLLATION() is a special function - its value is constant even if its argument is not costant.
  • Crash when using ANY predicand with redundant subquery in GROUP BY clause (MDEV-29139)
    • A query with a subuquery in this form could cause a crash:
... ANY (SELECT ... GROUP BY (SELECT redundant_subselect_here)) ...
  • MariaDB Server SEGV on INSERT .. SELECT (MDEV-26427)
    • Certain queries in form "INSERT ... SELECT with_aggregate_or_window_func" could cause a crash.
  • restore_prev_nj_state() doesn't update cur_sj_inner_tables correctly (MDEV-28749)
    • Subquery semi-join optimization could miss LooseScan or FirstMatch strategies for certain queries.
  • Optimizer uses all partitions after upgrade to 10.3 (MDEV-28246)
    • For multi-table UPDATE or DELETE queries, the optimizer failed to apply Partition Pruning optimization for the table that is updated or deleted from.
  • Range optimizer regression for key IN (const, ....) (MDEV-25020)
    • The issue can be observed on MariaDB 10.5.9 and later versions which have the fix for MDEV-9750. That fix introduceds optimizer_max_sel_arg_weight.
    • If one sets optimizer_max_sel_arg_weight to a very high value or zero (which means "unlimited") and runs queries that produce heavy-weight graphs, they can observe a performance slowdown, e.g.:
table.keyXpartY [NOT] IN ( ... )
  • Wrong result with table elimination combined with not_null_range_scan (MDEV-28858)
    • If one runs with optimizer_switch='not_null_range_scan=on' (which is not enabled by default), a query that does a join and has const tables could produce a wrong result.
  • Assertion `tmp >= 0' failed in best_access_path (MDEV-28882)
    • If one uses histogram_type=JSON_HB, has collected a histogram of that type and runs a query that selects a very narrow range near histogram end, they can hit an assertion in the optimizer due to rounding errors in the histogram causing negative selectivity.
Spider JSON
  • JSON_TABLE: extract document fragment into JSON column (MDEV-25875)
CONNECT General Security Changelog

For a complete list of changes made in MariaDB 10.9.2, with links to detailed information on each push, see the changelog.

MariaDB foundation

Versienummer 10.9.2
Releasestatus Final
Besturingssystemen Windows 7, Linux, BSD, macOS, Solaris, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website MariaDB
Download https://downloads.mariadb.org/mariadb
Licentietype Voorwaarden (GNU/BSD/etc.)

Reacties (5)

5
5
3
0
0
0
Wijzig sortering
Ik was al tijden geleden overgestapt op postgresql ivm de licentie en onderhoud.
@souplost & @jurroen : 20-25j geleden werkte ik met beide (maar voor simpele toepassingen). Na 20j wil ik mijn kennis eens updaten. In die tijd is me "beter" of sneller niet echt opgevallen (gezien ik geen enorme applicaties bouwde). Kunnen jullie me hierover wat in de juiste richting schoppen mbt voor en nadelen van beide (of alle in feite die drie)?
Ik ga het nog erger maken: MySQL, MariaDB en Percona zijn allemaal verwant (forks). In mijn directe omgeving is MariaDB het meest populair - een partij die Percona gebruikt "want beter te schalen". En ik zelf? Zeer sterke voorkeur voor PostgreSQL. Een vrij simpele applicatie maar die veel data moet verwerken werkt in mijn ervaring echt een stuk lekkerder op PostgreSQL.

Voorbeeldje: tijdens mijn opleiding (lang, lang geleden) vond ik het door hun aangeboden rooster echt een gedrocht. Frames, Comic Sans en glittergifjes. Kid you not. Initieell gebouwd op basis van MySQL/MariaDB - toen een query time van anderhalve seconde. Geswitcht naar PostgreSQL en dat maakte het miliseconden werk.

Maarrrr, als ik moet kiezen uit een van die drie - bijvoorbeeld voor een bestaande (web)applicatie *kuch* WordPress, dan is het MariaDB. Let wel: zeker als je InnoDB gebruikt kun je veel winst maken met een geoptimaliseerde config.
Zie https://www.ibm.com/cloud...ysql-whats-the-difference
Voor de Mariadb was ik al overgestapt naar PostgreSQL omdat dit product ge-include mocht worden in je eigen commerciële applicatie.
PostgreSQL is, mijn inziens, ook veel sneller met complexe queries. Ik begrijp ergens wel waarom de jonge broekies voor MySQL/MariaDB kiezen, gezien PostgreSQL wat 'stricter' is. Maar dat is weer een hele andere (wellicht wat filosofische) discussie :+

Op dit item kan niet meer gereageerd worden.