[MySQL] Problemen met import database

[mackey6879]

Mijn vraag:
Ik probeer een Wordpress website te verhuizen. De bijbehorende database probeer ik ook te verhuizen, maar bij het importeren in de nieuwe omgeving krijg ik de volgende foutmelding:

Fout
SQL-query:


-- --------------------------------------------------------

--
-- Tabel structuur voor tabel `tblnieuwsitemsolution`
--

CREATE TABLE `tblnieuwsitemsolution` (
`NieuwsItemId` bigint(20) NOT NULL AUTO_INCREMENT,
`NieuwsDatum` date NOT NULL DEFAULT '0000-00-00',
`NieuwsTitel` varchar(255) NOT NULL DEFAULT '',
`NieuwsSubtitel` varchar(255) DEFAULT NULL,
`NieuwsTekst` longtext NOT NULL,
`NieuwsImgsFileName` varchar(255) DEFAULT NULL,
`NieuwsArchief` tinyint(4) NOT NULL DEFAULT '0',
PRIMARY KEY (`NieuwsItemId`,`NieuwsItemId`,`NieuwsItemId`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=5
MySQL meldt: Documentatie

#1060 - Dubbele kolom naam 'NieuwsItemId'

Met vriendelijke groet,
Mackey

[AW_Bos]

Is die nieuwe database wel leeg?

[mackey6879]

yes

[AW_Bos]

Ik zie nu dat je drie dezelfde velden in je PRIMARY KEY hebt

Alsnog wel benieuwd hoe dat komt. welke manier van exporteren gebruik je? Zijn er mogelijkheden via SSH (PuTTY)?

[Voor 127% gewijzigd door AW_Bos op 01-03-2020 15:29]

[mackey6879]

Ik ben geen database expert. Ik werk direct in phpmyadmin.
Kan ik de primary keys gewoon verwijderen uit de database?

[Jaap-Jan]

Je kunt het gewoon fixen in je databasedump, maar het is wel de vraag hoe dit is gekomen.

[mackey6879]

AW_Bos schreef op zondag 1 maart 2020 @ 15:25:
Ik zie nu dat je drie dezelfde velden in je PRIMARY KEY hebt

Dat klopt en dat is volgens mij dus ook het probleem.

Alsnog wel benieuwd hoe dat komt. welke manier van exporteren gebruik je? Zijn er mogelijkheden via SSH (PuTTY)?

De website staat op dit moment bij deheeg gehost. Volgens mij kan ik niet via SSH de database exporteren. (weet ook niet hoe dat moet trouwens hoor)

[Room42]

mackey6879 schreef op zondag 1 maart 2020 @ 15:41:
[...] (weet ook niet hoe dat moet trouwens hoor)

Is wel te Googlen, hoor.

Maar jij kunt dus gewoon

SQL:

PRIMARY KEY (`NieuwsItemId`,`NieuwsItemId`,`NieuwsItemId`)

vervangen door:

SQL:

PRIMARY KEY (`NieuwsItemId`)

GoT Pro-tip: Zet je SQL-code tussen [code=sql] ... [/code]-blokken om hem lekker leesbaar te maken.

[AW_Bos]

kijk eerst eens hoe in phpMyAdmin de primairy keys ingesteld staan. Misschien dat je (door een bug in MySQL?) eerst wel drie dezelfde Primairy key's (PK's) kon aanmaken, en in de versie van de nieuwe MySQL niet meer.

Als je SSH hebt, is een export met Putty in no-time geregeld, net nog in no-time 100 MB gedumpt

[Voor 19% gewijzigd door AW_Bos op 01-03-2020 15:50]

[_JGC_]

Oh en als je dan toch bezig bent, flikker die engine=myisam eruit of maak er engine=innodb van.

[Room42]

_JGC_ schreef op zondag 1 maart 2020 @ 15:55:
Oh en als je dan toch bezig bent, flikker die engine=myisam eruit of maak er engine=innodb van.

Of hij doet het niet. Zo nou, heeft ie twee niet-onderbouwde stellingen waar ie, zonder kennis van zaken (dat is namelijk de situatie waar TS in zit), niks aan heeft.

[Voor 10% gewijzigd door Room42 op 01-03-2020 16:51]

[_JGC_]

Room42 schreef op zondag 1 maart 2020 @ 16:50:
[...]

Of hij doet het niet. Zo nou, heeft ie twee niet-onderbouwde stellingen waar ie, zonder kennis van zaken (dat is namelijk de situatie waar TS in zit), niks aan heeft.

Beetje onderzoek mag TS zelf ook wel doen lijkt me?

MyISAM is al enige tijd deprecated en wordt allang niet meer aangeraden om te gebruiken. De enige reden om het te gebruiken was fulltext search, maar dat doet MySQL sinds 5.6 ook al met InnoDB.
Aan de foutmelding te zien gebruikt ie MySQL 5.7 of hoger (of een afgeleide daarvan zoals MariaDB), die staan standaard in strict modus en slikken dergelijke dingen niet.

[Room42]

_JGC_ schreef op zondag 1 maart 2020 @ 17:58:
[...]

Beetje onderzoek mag TS zelf ook wel doen lijkt me?

TS gaf duidelijk aan niet in de materie te zitten, dus dan zo'n boude uitspraak (flikker even dit, doe even dat) geeft toch veel te weinig houvast over waar die dan naar moet zoeken.

MyISAM is al enige tijd deprecated en wordt allang niet meer aangeraden om te gebruiken.

Als je dit er nou meteen bijgezet had, was het tenminste duidelijk waar je het over had en waarom TS hiernaar zou moeten kijken. Zonder die context kun je er toch niks van maken? Laat staan dat ie de impact van zo'n wijziging kan overzien.

Leef je even in in een totale leek die gewoon zijn Wordpress-site online wilt hebben. MySQL is niet makkelijk te bevatten als je er niet volledig in zit of er echt mee werkt. Als je het enkel gebruikt voor je websiteje, krijg je normaal met dat soort zaken niet te maken.

[Voor 5% gewijzigd door Room42 op 01-03-2020 18:40]

[mackey6879]

Ik wil jullie allen bedanken voor de reacties, ben er zeker met de hulp van AW_BOS goed uit gekomen.

[Banpei]

_JGC_ schreef op zondag 1 maart 2020 @ 17:58:
[...]
MyISAM is al enige tijd deprecated en wordt allang niet meer aangeraden om te gebruiken. De enige reden om het te gebruiken was fulltext search, maar dat doet MySQL sinds 5.6 ook al met InnoDB.

MyISAM is zeker niet deprecated, zelfs niet in MySQL 8.0. Het wordt minder en minder gebruikt en de standaard is inderdaad sinds 5.5 InnoDB. Steeds minder features (zoals partitioning) staan het gebruik van MyISAM toe, maar je kunt nog steeds MyISAM gebruiken in 8.0.

Bij kleine wordpress sites zijn er nog steeds een goede redenen om MyISAM te blijven gebruiken: performance en geheugen. Als je een wordpress site hebt waar weinig in geschreven wordt (99% van de wordpress sites) heb je weinig aan de extra features van InnoDB. Sterker nog: je hebt een bufferpool nodig om de database in te stoppen die uiteindelijk niets toevoegd aan je applicatie. Als je een wordpress site op een kleine VPC host zonder dat er een externe database aanwezig is voor je queries kan MyISAM juist een performance boost geven. Ook als je Wordpress bijvoorbeeld in docker draait en MySQL als sidecar hebt hoef je op deze manier niet al te veel resources te gebruiken.