[PHP/Mysql] file schrijven en inladen in tabel

[Dorgaldir]

Hey,

ik wil via een php script een file wegschrijven naar de server en dan via mysql deze laten inladen. Nu zit ik met het issue dat ik vanuit mijn script niet kan schrijven naar een map in de /var/lib/mysql-files omdat de /lib file niet schrijfbaar is.
Als ik de file op een andere locatie zet onder /var/www/ dan kan ik de file wegschrijven, maar als ik dan een "LOAD DATA INFILE" query run dan krijg ik errors, eerst omdat de secure_file_priv nog op de mysql-files map stond, dit heb ik in een .cnf file opgelost, als ik nu "SHOW VARIABLES LIKE "secure_file_priv"" run dan krijg ik wel de nieuwe map te zien, maar als ik dan de query run dan krijg ik alsnog een error

code:

#29 - File '/var/www/html/file.TXT' not found (OS errno 13 - Permission denied)

Dit is op een ubuntu webserver die apache en mysql draait.

Hoe kan ik zorgen dat mysql wel die file kan uitlezen? Of hoe kan ik zorgen dat ik vanuit php wel kan wegschrijven naar die originele map?

[RobIII]

Dorgaldir schreef op donderdag 6 januari 2022 @ 23:47:
Hoe kan ik zorgen dat mysql wel die file kan uitlezen?

Zorgen dat mysql rechten heeft om die file te lezen

Dorgaldir schreef op donderdag 6 januari 2022 @ 23:47:
Of hoe kan ik zorgen dat ik vanuit php wel kan wegschrijven naar die originele map?

Zorgen dat php rechten heeft om in die map te schrijven (Which is a bad idea, by the way - ik zou gewoon /tmp gebruiken ofzo).

Zet de www-user en de mysql user samen in een groep en zet die groep op de file en je bent er lijkt me?

[ Voor 8% gewijzigd door RobIII op 07-01-2022 01:17 ]

[Dorgaldir]

RobIII schreef op vrijdag 7 januari 2022 @ 01:14:

Zorgen dat mysql rechten heeft om die file te lezen

dat trachte ik dus te doen maar dat lukte mij niet, er staan publiek lees en schrijfrechten op die map dus ik ging er van uit dat dat genoeg was, maar ik blijf de melding krijgen dat die map niet writable is

RobIII schreef op vrijdag 7 januari 2022 @ 01:14:

Zorgen dat php rechten heeft om in die map te schrijven (Which is a bad idea, by the way - ik zou gewoon /tmp gebruiken ofzo).

ja daar ging ik al van uit dat het geen goed plan was om /lib writable te maken ik vroeg het maar voor het geval er geen andere opties waren

RobIII schreef op vrijdag 7 januari 2022 @ 01:14:
Zet de www-user en de mysql user samen in een groep en zet die groep op de file en je bent er lijkt me?

ik probeer het zo even, alvast bedankt voor de info!

[eLScha]

Waarom laat je php niet zelf de data naar de database schrijven?

[Dorgaldir]

eLScha schreef op vrijdag 7 januari 2022 @ 09:15:
Waarom laat je php niet zelf de data naar de database schrijven?

We hebben sowieso ook de file nog nodig, dus we moeten hem sowieso wegschrijven.

De reden dat ik dat nog niet geprobeerd heb is omdat het over een file van meer dan 30MB gaat met ruwweg 1.5mil lijnen aan data, ik was niet zeker of ik dit zomaar zonder veel issues door een php script kan pushen.

[eLScha]

Er is te weinig informatie om te oordelen, maar het voelt alsof je eens naar het grotere plaatje zou moeten kijken. Dit lijkt niet heel efficient.

[PainkillA]

Dorgaldir schreef op vrijdag 7 januari 2022 @ 10:05:
[...]


We hebben sowieso ook de file nog nodig, dus we moeten hem sowieso wegschrijven.

De reden dat ik dat nog niet geprobeerd heb is omdat het over een file van meer dan 30MB gaat met ruwweg 1.5mil lijnen aan data, ik was niet zeker of ik dit zomaar zonder veel issues door een php script kan pushen.

er mist nog heel wat data om er iets zinnigs over te kunnen zeggen. ik zou aanraden om in je database geen file contents te gaan opslaan en alleen het pad of filename op te slaan. Php kan prima grote files naar de gebruiker sturen maar dat moet dan wel streaming gebeuren en niet de complete file eerst in memory via php inladen. Files zou ik overigens eerder in een objectstore zoals amazon s3 zetten zodat backup, security etc uit handen wordt genomen en je zo beter kan schalen

[RobIII]

PainkillA schreef op vrijdag 7 januari 2022 @ 13:12:
[...]


er mist nog heel wat data om er iets zinnigs over te kunnen zeggen. ik zou aanraden om in je database geen file contents te gaan opslaan en alleen het pad of filename op te slaan. Php kan prima grote files naar de gebruiker sturen maar dat moet dan wel streaming gebeuren en niet de complete file eerst in memory via php inladen. Files zou ik overigens eerder in een objectstore zoals amazon s3 zetten zodat backup, security etc uit handen wordt genomen en je zo beter kan schalen

TS probeert data uit een CSV te importeren, niet de CSV zélf (of een ander bestand) als blob/"bestand" in de DB te zetten

[Kalentum]

Dorgaldir schreef op vrijdag 7 januari 2022 @ 10:05:
[...]


We hebben sowieso ook de file nog nodig, dus we moeten hem sowieso wegschrijven.

De reden dat ik dat nog niet geprobeerd heb is omdat het over een file van meer dan 30MB gaat met ruwweg 1.5mil lijnen aan data, ik was niet zeker of ik dit zomaar zonder veel issues door een php script kan pushen.

Ik zou om diverse redenen (security, complexiteit) LOAD DATA ten alle tijde vermijden, tenzij het om een eenmalige import gaat. Misschien dat de LOCAL modifier nog wat behulpzaam kan zijn, het lijkt alsof je dan in geval van een wat logischer directory kan importeren.

Maar goed, ik zou dus altijd eerst proberen een gewone import via een script proberen, in jouw geval dus PHP. Dat heeft veel voordelen en is veel flexibeler. Je kan bv retryen, pauzeren etc. Maar alles staat of valt met je vereisten, bv hoe vaak moet dit gebeuren, wordt het door gebruikers geinitieerd etc etc.

[Dorgaldir]

Kalentum schreef op vrijdag 7 januari 2022 @ 13:26:
[...]


Ik zou om diverse redenen (security, complexiteit) LOAD DATA ten alle tijde vermijden, tenzij het om een eenmalige import gaat. Misschien dat de LOCAL modifier nog wat behulpzaam kan zijn, het lijkt alsof je dan in geval van een wat logischer directory kan importeren.

Maar goed, ik zou dus altijd eerst proberen een gewone import via een script proberen, in jouw geval dus PHP. Dat heeft veel voordelen en is veel flexibeler. Je kan bv retryen, pauzeren etc. Maar alles staat of valt met je vereisten, bv hoe vaak moet dit gebeuren, wordt het door gebruikers geinitieerd etc etc.

Het is een actie de elke dag opnieuw uitevoerd dient te worden rond middernacht.
Ik heb in het verleden al issues gehad met grote files via php te importeren in mysql, vandaar dat ik LOAD DATA ben beginnen gebruiken, die deed het toen wel...

[Kalentum]

Dorgaldir schreef op vrijdag 7 januari 2022 @ 13:39:
[...]


Het is een actie de elke dag opnieuw uitevoerd dient te worden rond middernacht.
Ik heb in het verleden al issues gehad met grote files via php te importeren in mysql, vandaar dat ik LOAD DATA ben beginnen gebruiken, die deed het toen wel...

Wat voor issue had je dan?

[DJMaze]

Kalentum schreef op vrijdag 7 januari 2022 @ 16:59:
Wat voor issue had je dan?

@Dorgaldir heeft vast "out of memory" of "timeout".

Is wel raar want je kan prima bestanden van 1GB verwerken (snel is anders).

[Kalentum]

DJMaze schreef op vrijdag 7 januari 2022 @ 20:29:
[...]

@Dorgaldir heeft vast "out of memory" of "timeout".

Is wel raar want je kan prima bestanden van 1GB verwerken (snel is anders).

De bestanden zijn blijkbaar 30 MB dus tja..., Ik ben benieuwd wat dan het probleem is.

[ Voor 6% gewijzigd door Kalentum op 07-01-2022 20:52 ]