Ik doe een keer per week in crontab -e een mysqldump, dat werkt al maanden maar opeens blijft het aangemaakte bestand leeg. De errorlog meldt niks en ik krijg ook geen mail dat er iets niet werkt.
Niet per definitie, dat hangt af van hoe de mysql build in elkaar is gezet. Het kan best zo zijn dat /etc/my.cnf belangrijker is dan /etc/mysql/my.cnf, maar het enige dat je kunt doen is kijken wat er gebeurt door verschillende configs te plaatsen en een query uit te voeren als SHOW VARIABLES., en daardoor weten wat er gebeurt.
Ik gebruik al jaren geen mysql meer, en ik heb ook geen zin om een mysql server te installeren voor een experiment. Zonde van de tijd ;-)
Dus etc/my.cnf nu nutteloos omdat etc/mysql/my.cnf wordt gebruikt?
Dat kun je nazoeken met dit commando:
mysqladmin | head
(Omdat mysqladmin vrij veel output geeft en de relevante informatie bovenaan staat, gebruik ik 'head' om alleen de eerste 10 regels te tonen.)
Ergens in de output staat iets als:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
Oftewel: eerst wordt er gekeken naar /etc/my.cnf, daarna wordt gekeken naar /etc/mysql/my.cnf en tot slot wordt er gekeken of er in je home-directory een .my.cnf staat.
Die .my.cnf kun je gebruiken voor persoonlijke instellingen. Zelf gebruik ik hem vooral om het wachtwoord voor de betreffende gebruiker te configureren, zodat cronjobs geen wachtwoord hoeven op te geven.
Let op dat wanneer een instelling gedaan wordt in meerdere cnf-bestanden, de instelling wordt gebruikt die het laatst wordt verwerkt. Instellingen in /etc/mysql/my.cnf overrulen dus instellingen in /etc/my.cnf.
Die .my.cnf kun je gebruiken voor persoonlijke instellingen. Zelf gebruik ik hem vooral om het wachtwoord voor de betreffende gebruiker te configureren, zodat cronjobs geen wachtwoord hoeven op te geven.
In het mysqldump commando kun je refereren aan een config-file door middel van --defaults-file=/path/to/db.cnf (alwaar je een apart kopje [mysqldump] maakt). Is dit wat je bedoelt?
[quote="Willem vp op 21/10/2016 09:10:40"]Die .my.cnf kun je gebruiken voor persoonlijke instellingen. Zelf gebruik ik hem vooral om het wachtwoord voor de betreffende gebruiker te configureren, zodat cronjobs geen wachtwoord hoeven op te geven.
In het mysqldump commando kun je refereren aan een config-file door middel van --defaults-file=/path/to/db.cnf (alwaar je een apart kopje [mysqldump] maakt). Is dit wat je bedoelt?
[/quote]
Nope. Met --defaults-file zorg je ervoor dat alleen het opgegeven bestand wordt gebruikt en dat alle overige my.cnf-bestanden worden genegeerd.
Wanneer je instellingen doet in ~/.my.cnf, dan worden de normale config-bestanden verwerkt en aangevuld met (of vervangen door) instellingen die in ~/.my.cnf staan. In mijn situatie heb ik bijvoorbeeld een aantal (functionele) gebruikers die 'dingen moeten doen' met MySQL. Vooral wanneer het scripts betreft die automatisch worden gestart (bijvoorbeeld via een cronjob) wil je niet dat er een wachtwoord moet worden ingevoerd. Het wachtwoord in de scripts opnemen door een optie --password toe te voegen is niet wenselijk. Ik configureer in zulke gevallen het wachtwoord in ~/.my.cnf.
Wat soms ook wel handig is, is om bij sommige gebruikers de optie i-am-a-dummy=true te configureren. Die gebruikers kunnen dan geen update of delete doen zonder een where/limit-clause, en select statements geven maximaal 1000 rijen.
geeft:
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
Ondanks het opnieuw installeren van mysql, kreeg ik vanochtend weer de error running shared postrotate script for '/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/error.log '
Zou ik misschien de inhoud van etc/mysql/my.cnf moeten kopieren naar /etc/my.cnf?
