[mysql 8 / mariadb10.2] kan database niet verwijderen

[Workaholic]

Ik heb een oude database die ik niet verwijderd krijg op mijn debian omgeving. Ik krijg deze melding:

code:

 ERROR 1709 Index column size too large. The maximum column size is 767 bytes.

Systeem specs:
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-20-amd64
Architecture: x86-64
Mysql Version: 8.0.29
Mariadb: 10.2

Hebben jullie enige idee hoe ik dit kan tackelen? De database is oud en niet meer nodig.

Oplossingen (aanpassing naar UTF8, large prefix aan, rowformat dynamic) die op internet zijn aangeven werken niet (omdat elk commando of aanpassing wat ik gebruik deze foutmelding teruggeeft). In shell, in Phpmyadmin etc.

Iemand suggesties? Ook het legen of verwijderen van tables in de database lukt niet etc.

[ Voor 11% gewijzigd door Workaholic op 11-05-2022 20:22 ]

[CH4OS]

Oplossing:
Waarschijnlijk zit er een index op een varchar(255) kolom in een van de tabellen.
Ik denk dat als je die weghaalt, dat je daarna de database prima kan verwijderen.
Mocht dit niet direct werken, dan de lengte van de kolom inkorten, bijvoorbeeld naar 190, dan zit je altijd onder de limiet van MySQL en moet het verwijderen sowieso werken.

Details:
Je krijgt de melding omdat UTF-8 (de foute UTF-8 by the way) 3 bytes gebruikt per karakter, met 255 tekens heb je dan 765 bytes. Dat zou dus precies passen. De juiste UTF-8, utf8mb4 geheten in MySQL, gebruikt er (je raadt het waarschijnlijk al) 4 bytes per character en dan kom je dus op 1020 bytes uit, wat te groot is voor de index.

[ Voor 14% gewijzigd door CH4OS op 11-05-2022 20:28 ]

[Workaholic]

Het probleem is dat ik geen wijzigingen kan doen binnen deze specifieke database - sql blijft deze error teruggeven.

[CH4OS]

In het uiterste geval kun je de MySQL service stoppen en de files van de database van het filesystem verwijderen. Daarna kan je de permissies verwijderen uit MySQL.

[Workaholic]

Blijft de database dan niet ergens in een system config of main table gekoppeld staan? Dus feitelijk een verwijziging naar deze database binnen mysql (dus het verwijderen van files zou wel werken maar het systeem denkt dat de DB er nog is?)

[ Voor 47% gewijzigd door Workaholic op 11-05-2022 20:31 ]

[CH4OS]

Ik zou eerst proberen de aanpassingen op de database te doen die ik zojuist aangaf, eventueel met het inkorten van de lengte van de betreffende kolom.

Na het verwijderen van de bestanden via het filesystem moet je uiteraard de permissies nog verwijderen.
Ik weet verder de context niet waarvoor de database überhaupt werd gebruikt, dus ik weet niet of het nog ergens mee gekoppeld staat. Maar in principe zijn databases niet aan elkaar gekoppeld. De enige "koppeling" zijn de grants (permissies) die in de mysql database opgeslagen worden.

[Workaholic]

Thanks - er stonden maar twee tabellen in en elke mutatie of actie - of zelf het openen van de tabel in phpmyadmin geeft deze foutmelding.

Heb daarom als Plan B (waarvoor dank) de database verwijderd in de /mysql/data dir. Hier is hij nu niet meer zichtbaar. Als ik vervolgens Mysql herstart en via shell show databases doe - staat hij er nog bij. Vergeet ik iets?

[CH4OS]

Waarschijnlijk staan die nog in de mysql database. Maar waarom heb je niet gewoon eerst de eerst geboden oplossingen geprobeerd? Ik heb een beetje het idee dat je niet begrijpt wat er aan de hand is.

[ Voor 22% gewijzigd door CH4OS op 11-05-2022 20:41 ]

[Workaholic]

CH4OS schreef op woensdag 11 mei 2022 @ 20:39:
Waarschijnlijk staan die in de mysql database dan. Maar waarom heb je niet gewoon eerst de eerst geboden oplossingen geprobeerd? Ik heb een beetje het idee dat je niet begrijpt wat er aan de hand is.

Zoals gezegd kan ik jouw aanpassingen niet doorvoeren, elke aanpassing of commando/query geeft een error

[CH4OS]

Niet dat jij er nog wat aan hebt, maar mocht iemand in de toekomst langs komen: het kan ook aan de collatie settings van MySQL liggen (deze oplossing vind ik net ook nog).

Standaard gebruikt MySQL (terecht) utf8mb4 als collatie, die kan je in my.ini naar UTF-8 zetten, of in de connectie instellingen van de specifieke applicatie waarmee je met de database verbindt. Dan hou je dus wat bytes over en zou het moeten kunnen.

Bron: https://qa.ostack.cn/qa/?qa=602956/

Workaholic schreef op woensdag 11 mei 2022 @ 20:42:
Zoals gezegd kan ik jouw aanpassingen niet doorvoeren, elke aanpassing of commando/query geeft een error

Voor nu om het voor jou op te lossen, moet je eea handmatig opschonen in de mysql database. Doe wel voorzichtig, want als je hier iets fout doet, kan je MySQL zelf om zeep helpen! Maak dus eerst een backup!

[ Voor 30% gewijzigd door CH4OS op 11-05-2022 20:50 ]

[luukvr]

Je zou de overige schema's (die je wilt houden) kunnen dumpen en dan inlezen in een nieuwe setup.

Had ook ergens gelezen dat je tabellen van het ene naar een ander schema kan verplaatsen, degene die dan niet lukken zijn bugged, misschien kan je het probleem dan lokaliseren.

[Ben(V)]

CH4OS schreef op woensdag 11 mei 2022 @ 20:47:
Niet dat jij er nog wat aan hebt, maar mocht iemand in de toekomst langs komen: het kan ook aan de collatie settings van MySQL liggen (deze oplossing vind ik net ook nog).

Standaard gebruikt MySQL (terecht) utf8mb4 als collatie, die kan je in my.ini naar UTF-8 zetten, of in de connectie instellingen van de specifieke applicatie waarmee je met de database verbindt. Dan hou je dus wat bytes over en zou het moeten kunnen.

Even voor de duidelijkheid voordat meelezers hier de verkeerde conclusie trekken.

UTF-8 is een standaard waarbij de char size kan variëren tussen 1 en 4 bytes.
Waar jij het over heb is de MySQL "utf8" wat een alias is voor "utf8mb3", maar dat is dus geen "UTF-8".

En hoe je tabellen met "utf8mb3" codering kunt omzetten naar "utf8mb4" kun je hier lezen
https://dev.mysql.com/doc...t-unicode-conversion.html

Overigens denk ik niet dat dit het probleem is/was anders had hij niet op elk commando een error gekregen.

[Feanathiel]

Wellicht gerelateerd? https://bugs.mysql.com/bug.php?id=102597

Uiteindelijk hebben ze die bug gefixed zodat het niet meer kan voorkomen, wellicht handig voor de toekomst, maar daar hebben we helaas nu niks aan.

Wat mij op die bug-pagina opvalt is: "upgrade to any 8.0.x version (tested on 8.0.22) and the table become inaccessible." - Is deze tabel aangemaakt op een lagere MySql versie ( lager dan 8 )? Anders ben ik bang dat je 'm niet op de normale manier kan verwijderen.

[Workaholic]

Feanathiel schreef op zaterdag 14 mei 2022 @ 12:20:
Wellicht gerelateerd? https://bugs.mysql.com/bug.php?id=102597

Uiteindelijk hebben ze die bug gefixed zodat het niet meer kan voorkomen, wellicht handig voor de toekomst, maar daar hebben we helaas nu niks aan.

Wat mij op die bug-pagina opvalt is: "upgrade to any 8.0.x version (tested on 8.0.22) and the table become inaccessible." - Is deze tabel aangemaakt op een lagere MySql versie ( lager dan 8 )? Anders ben ik bang dat je 'm niet op de normale manier kan verwijderen.

Ja is idd een bug vrees ik, kom inderdaad vanaf een oude versie af. Heb de files handmatig verwijderd maar ben helaas niet kundig genoeg om de "restjes" op te ruimen. Als ik SHOW databases doe dan staat hij er nog tussen, delete lukt nu (logisch) ook niet, schema error. Maar even kijken of ik een handige collega kan vinden die met mij meekijkt want zou niet weten waar ik moet zoeken in Phpmyadmin voor het opruimen van deze tabel/db.