I waited for upstream to fixt that issue.

It will take some time, before 10.2.12 will come to f27, however the 10.2.12 is already builded for rawhide and F27 build is on the way.

If you need that fix immediately, use them.

Rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1015579

F27: (still building, but x86_64 is already available)
https://koji.fedoraproject.org/koji/buildinfo?buildID=1015665

After a manual update to 10.2.12 from those x86_64-packages I still get "#mysql50#.rocksdb" in a "show databases".

And it is probabbly caused by some residual files left in datadir.
I'd like you to confirm my theory.

---

When I do following test: (ran as root in a folder with downloaded 10.2.12 RPMs)

  dnf remove -yq "*mariadb*" "*mysql*"
  rm -rf /var/lib/mysql
  dnf list installed | grep -e mariadb -e mysql

  dnf install -yq mariadb-server
  dnf list installed | grep -e mariadb -e mysql
  systemctl start mariadb
  echo "show databases" | mysql | grep rocks

  dnf update -yq ./*rpm
  dnf list installed | grep -e mariadb -e mysql
  echo "show databases" | mysql | grep rocks

It will show, that the update to 10.2.12 will show the RocksDB entry no more.

However, this test does not work if the datadir was preserved at the beginning, because I had some duplicate RocksDB folders there.

After this procedure, the only RocksDB folder left in datadir is '#rocksdb'.

  ls -1 /var/lib/mysql/ | grep rock
  #rocksdb

If you have any other RocksDB directories there, they are most likely the cause of the issue.

I was unable to wipe my local mariadb completely right now, but looked what rocksdb-directories were there, removed them and restarted mariadb.

Before that I had .rocksdb and #rocksdb. After deleting the directories and restarting there is only #rocksdb. And "show databases" doesn't show rocksdb anymore.

So yes, it seems to work after the upgrade. It's just that there is no migration-script or the like.

Glad to know it solved your issue.

I'll leave this bug report open till >=10.1.12 in f27 stable repository.

mariadb-10.2.12-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c82f2773c

mariadb-10.2.12-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c82f2773c

mariadb-10.2.12-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-66833616aa

mariadb-10.2.12-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-66833616aa

mariadb-10.2.12-5.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-66833616aa

mariadb-10.2.12-5.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-66833616aa

I have an installation where mysqldump --all-databases fails with:

mysqldump: Got error: 1102: "Incorrect database name '#mysql50#.rocksdb'" when selecting the database

This appeared after the update from mariadb-3:10.2.9-3.fc27.x86_64 to 3:10.2.10-2.fc27.x86_64 and has not gone away after pulling 3:10.2.12-5.fc27.x86_64 from testing.

I assume I'm supposed to manually delete something to get things working properly again, but... exactly what should I remove?  This is a live installation with a whole bunch of data so I don't just want to go deleting things randomly.  To my knowledge I have never used rocksdb but my database directory contains both ".rocksdb" and "#rocksdb".

@Jason: #rocksdb is the right one, the other you can move away. If you never used rocksdb just feel free to move away both and restart.

Thanks; I moved the .rocksdb directory out of the way and now mysqldump is working as expected.

mariadb-10.2.12-5.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Just found the #rocksdb dir messing up backups for me.  The dir exists on most of the F27 boxes I admin (but strangely not all -- I think it had to do with when I upgraded to F27 from 26, later upgrades don't have the dir).

Shouldn't an errata go out that gets rid of this dir?  An rpm put this dir in there (with files), which presumably was owned by the rpm, and then an errata does not have that dir in the rpm, but it stays left behind on our boxes?  As an unowned dir/file, unowned by any rpm?  Ugly.

Why can't an errata clean up the mess left behind by an erroneous errata?

I wonder how many people out there are silently having failed mysql backups... worse still, when I noticed this I thought I had been hacked at first.  I've never used anything called "rocksdb".