possible issue with mariadb

[Hardcore-fs]

Hi, if you are already running synology git 9.4.4 , it already auto upgrades from mariadb5 to mariadb 10

but note that the synology backup systems also use mariadb5.

this can leave a situation where both mariadb5 & mariadb10 are in the system.

if you then update to gitlab 10.0.2 using this repository, it seems to get confused that mariadb5 is STILL the default database for gitlab

Yep confirmed... if you were on a previous version of synology GIT prior to 9.4.4, not only does it upgrade the maria from 5 ->10 BUT it leaves all the git crap in the old maria 5 db active

so ... you end up with TWO databases running on different ports, with the 5 running outdated git info, but the new 9.4.4 running from the MDB10

I fixed this by shutting down the MDB5 , leaving the already MDB10 (from 9.4.4) running and then doing a update from 9.4.4->10.2

clearly, some sort of better instruction or detection is needed for boundary cases.

[jboxberger]

Could you please specify what you mean with "synology backup systems"...

I didn't expect that people will install 10.0.2 over original 9.4.4-0050 if there is a newer 10.2.5 available :-(. Do you mean this Update would lead to a confused MariaDB5/10 state?

Thanks for the issue!

[Hardcore-fs]

synology backup programs "hyper backup" uses maria db5.

just tried an update with 10.2.5, & it also does the same, IF MDB5 & MDB10 are running.

The confusion is caused by synology....... prior to 9.4.4 they used MDB5 when you do a synology upgrade to 9.4.4, it MIGRATES the MDB5 to MDB10 and updates the port info in GIT 9.4.4

BUT , it LEAVES all the old info in MDB5 and the git_user account still in MDB5, even AFTER the MDB10 success.

it seems that if BOTH MDB5 & MDB10 are running, this confuses the 10.2.5 update, and it tries to take the data from the MDB5 database.

I have just tested this situation on my synology. by taking it BACK to 9.4.4, turning OFF MDB5 (whilst leaving on the MDB10) and then the 10.2.5 update installed first time.

now I know this, i will go back into MDB5 & delete the old dead git_user data schema.

[jboxberger]

ok i will check this and see what happens. thanks!

[jboxberger]

Ok now i got you.

10.0.2 and anything below 10.1.4 is NOT COMPATIBLE with MDB10. As i already mentioned before: "I didn't expect that people will install 10.0.2 over original 9.4.4-0050 if there is a newer 10.2.5 available" ...

As my update Test shows, following combinations are possible.

To solve the Problem i removed old versions below 10.1.4 to preven people doin unexpected things :-).

[razorfish-sl]

The issue is the fact that WHEN you do a synology upgrade to 9.4.4 BEFORE using your packages

The sinology LEAVES BEHIND and active mariadb5.

i think your scripts are designed to be able to adapt to either an upgrade to from pre 9.4.4 OR post 9.4.4 to your 10.X

I think that your script picks up the the old dead mariadb5 on post 9.4.4 migrated upgrades rather than the new mariadb10.

I tested this on another sinology i have with an old GIT pre 9.4.4, and exactly the SAME happened The synology upgraded the synology git package to 9.4.4 migrated to mariadb10, but left behind a mariadb5, so BOTH mariadb5 & mariadb10 were left running. with ACTIVE GIT_user accounts.

It only happends on a synology upgrade, if you NEVER had git on your synology and installed the latest synology 9.44 package , you ONLY get mariadb10 and the upgrade works perfectly.

[jboxberger]

Hello razorfish-sl,

you're right. The problem appears if you update the STOCK 9.4.4-0050 to ANY Version before 10.1.4 (9.5.2, 10.0.2, 10.1.1). The Problem is that this packages do not use the MDB10 mysql.sock and therefore connect automatically to the MDB5... the old database on MDB5 is renamed during migration process and because of this GitLab can't find the database. The problem is solved since 10.1.4 and the MDB5. To prevent the problem i removed the old packages (9.5.2, 10.0.2, 10.1.1).

Have you fixed your installation yet? The problem should solve itself when you install 10.1.4 or higher.

Before MDB10 MIgration:

After MDB10 MIgration:

[razorfish-sl]

Yes... no sweat... already fixed, just rolled back to 9.4.4 then went to 10.2 I'm about to give Synology a kicking email for leaving their crap around half upgraded

[jboxberger]

This was not synology's fault. My package is designec to be able to install over the original package. Since i am with the Gitlab version far ahead synology ( synoloyg: v9 my version:10 ) you can install any of my versions over the original synology package. In the Version 9.4.4-0050 synology migrates to MDB10 ... but my 10.0.2 version (which was released 2 months before 9.4.4-0050) was still using MDB5. An becasue of the greater version number of my package you were able to install my "old" 10.0.2 MDB5 package over the 9.4.4-0050 MDB10 package.

Synology has nothiung to do with this issue and i tested the migration fom 9.4.4-0024 to 9.4.4-0050 or to 10.1.4 (My new MDB10 package) and everthing work fine. This is absolutely correct that the MDB5 database is renamed and not deleted. This is a backup to be able to revert the update if the migration went wrong and because of the rename it can not be used accidently by the application.

I removed the 10.0.2 and 10.1.1 from download to prevent this problem. Just use the 10.1.4 or 10.2.5 this will work fine on any stock version.

Kind Reagrds

[razorfish-sl]

It IS Synologys fault, but not for the reasons you think. Specifically because on update to 9.4.4 before you were even on the scene (10.0.2): 1.They half migrated to mariadb10, THEN left behind a mariadb5 database and schema with EXACTLY the same information.

2. PLUS TWO "dead" containers in the docker.

The fact that they leave an old outdated maria5db hanging around is a security risk, at the very least they could print instructions for clean up manually, or a warning.

The fact that your initial package is impacted by this is a different matter, since even If i had not gone to your GIT there would still be a half a***d attempt at an upgrade by synology packages when THEY transitioned to 9.4.4

It's also NOT the first time that SYNOLOGY have thrown together packages and done poor upgrades and it's not the first time I have dealt with their programmers directly .. lets just say there is history both on hardware & software design. On my initial contact they made it clear they don't really care about the GIT... since it's not a "core business and just copied from some place else....."