I have a project in php, there I connect to the server via ssh and my task is to change the postgresql.conf parameters.
I tried this:
psql -Upgadmin -p 11935 -d postgres -c array_nulls=off
ERROR: syntax error at or near "array_nulls"
LINE 1: array_nulls=off
^
or should I change the settings in postgresql.conf using sed, which command should I use?
Any server setting that you succeed in changing with psql will only last as long as your session. To make the change persist, you have to edit postgresql.conf, either with your favorite text editor (vim, emacs, etc.) or with a utility program (sed, awk, etc.). Everything that follows assumes that you have suitable privileges to edit postgresql.conf.
Your first job is to find it. Different Linux distributions store it in different places. In Ubuntu, it's in
/etc/postgresql/9.4/main
^^^
Note the version number. Different for each version of PostgreSQL, of course. If I wanted to change a setting, I'd do this after putting the file under version control.
$ sudoedit /etc/postgresql/9.4/main/postgresql.conf
[sudo] password for mike:
Then find the setting and change it. Here's what the relevant section of postgresql.conf looks like here.
#------------------------------------------------------------------------------
# VERSION/PLATFORM COMPATIBILITY
#------------------------------------------------------------------------------
# - Previous PostgreSQL Versions -
#array_nulls = on
I'd change the setting to
array_nulls = off # array_nulls = on
This kind of change usually requires either a reload or a restart of the PostgreSQL dbms.
Related
I am trying to figure out how to change MySQL configuration before a Travis CI test run. We are using the "sudo:false" directive, I think to use containers...I'm not the best devops person.
But even when I set sudo to true, I can't restart MySQL after I try to add lines to "/etc/mysql/my.cnf".
So,
- cat "some/directory/my.cnf" | sudo tee -a /etc/mysql/my.cnf
- sudo /etc/init.d/mysql restart
gives me: "start: Job failed to start", but I don't even want to use sudo. For PHP config, I can do something like:
- echo "apc.shm_size=256M" >> ~/.phpenv/versions/$(phpenv version-name)/etc/php.ini
but I can't see anything in my home folder about MySQL.
I also know about:
- mysql -e "SET GLOBAL innodb_buffer_pool_size = 512M;"
but the things I want to set give me:
ERROR 1238 (HY000) at line 1: Variable 'innodb_buffer_pool_size' is a read only variable
So, I'm at a loss on how to accomplish changing MySQL configuration on Travis CI, and every internet search and method I've tried has failed me.
innodb_buffer_pool_size cannot be dynamically changed until MySQL 5.7.5. What version are you using?
Before that version, here are some options:
Modify /etc/my.cnf (or wherever it is located)
Assuming my.cnf has an 'include' at the end, then temporarily add a file to the directory mentioned. It needs 2 lines [mysqld] and innodb_buffer_pool_size=512M; then restart mysqld.
Add --innodb_buffer_pool_size=512M to the launching of mysqld.
Other "VARIABLES" may, or may not, be dynamically settable. Research each one separately.
i present a .travis.yml configuration that allows you to run and restart mysqld without using sudo - the logic is along the lines of:
just out of interest, why can't you use sudo?
obtain the generic linux .tar.gz from https://dev.mysql.com/downloads/mysql/ in before_script using wget - store the .tar.gz within a directory that will be cached - don't do this if the file already exists
unpack the .tar.gz to the cached directory - don't do this if the unpack target already exists
scrub the error log and recreate the .cnf file
now in script, start mysqld for the first time, wait for a bit, check that it's running, then stop it
make any change to the config you want
start mysqld for the second time, wait for a bit, check the config change, then stop it
the proof .travis.yml (mysql 5.6.40 generic linux 64-bit) is here: https://github.com/knyrb/mysql-travisci/blob/master/.travis.yml - here is a (non-working) rough idea of the contents:
before_script:
<..snip..>
- if [ -f 'scripts/mysql_install_db' ]; then ./scripts/mysql_install_db --defaults-file="$TCI_D_MYSQL_ROOT/my.cnf"; fi
script:
<..snip..>
- bin/mysqld --defaults-file="$TCI_D_MYSQL_ROOT/my.cnf" --socket=/tmp/.thesock &
- bin/mysqladmin --defaults-file="$TCI_D_MYSQL_ROOT/my.cnf" --socket=/tmp/.thesock ping
- export TCI_MYSQL_PID_1="`cat $TCI_D_MYSQL_ROOT/mysql.pid`"
- kill -SIGTERM $TCI_MYSQL_PID_1
<..snip..>
after_success:
<..snip..>
after_failure:
<..snip..>
- cat "$TCI_D_MYSQL_ROOT/mysql.err"
discussion left for posterity:
as you've identified, there are certain configuration parameters in mysql that can only be set prior to the server starting viz. anything that is 'dynamic: no' in table 14.13 for mysql 5.6 - i restate the obvious fwiw: the php parameters are dynamically inflicted on the php process via php.ini
(never tested this - don't know if it works - the constraint was 'no sudo' and this method clearly requires sudo) first off, have you tried using the service binary (https://linux.die.net/man/8/service) instead of a direct call to mysql? viz. https://docs.travis-ci.com/user/database-setup/#MySQL-5.7 :
before_install:
- sudo mysql -e "use mysql; update user set authentication_string=PASSWORD('new_password') where User='root'; update user set plugin='mysql_native_password';FLUSH PRIVILEGES;"
- sudo mysql_upgrade
- sudo service mysql restart
what case(s) are you testing by changing these mysql parameters prior to each test's runtime as distinct from configuring them 'permanently' in the test instance db server?
assuming your mysqld is firing up at container start via services: mysql? could you configure travis to start mysqld specifically in before_install or script and specify the parameters that you want at start time, with mysqld running under the ci framework travis (i think this should allow it to start/stop/restart etc without any sudo use, but i haven't tested it) (see: https://github.com/knyrb/mysql-travisci for a proof of concept)
see: https://docs.travis-ci.com/user/database-setup/#MySQL, which hints the possibility (although with jackrabbit),
no: must run mysqld as root to switch user though you would run mysqld --user=travis (https://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_user), or maybe in the cnf file with [mysqld] user=travis directive (https://dev.mysql.com/doc/mysql-security-excerpt/5.6/en/changing-mysql-user.html)
(never tested this but it should work as well) another option might be to have a github project for each specific environment test you want to perform, with mysqld configured to run with its limiting parameters already set: your tests would be per container, rather than with interim restarts (possibly insane, depending on how bad you want it!)
(if your tests are performance related, remember to give the db a/ some warmup queries before you start measuring)
i ask purely out of interest: when it comes to testing different environments and configuration limits, my humble opinion will always favour a 'more is more' approach!
(never tested this either) not sure if you're using a recent enough version of mysql for this option to work, but i see there is an instruction in mysql 8 restart
this might work for you if you can have a mysql stored proc trigger a restart of the database service from a priveleged account calling a stored proc - you would call this stored proc then wait for the server to restart, say with one of the following methods:
a call to sleep did the job in the proof (it won't account for failure - but the ci build fails if any process returns != 0)
if your using a local unix/ domain socket, wait on the file /tmp/mysql.sock (or your equivalent) using any of the methods here: https://superuser.com/questions/878640/unix-script-wait-until-a-file-exists while .. sleep, inotifywait from the inotify tools; or from within python using inotify.adapters.InotifyTree().eventgen() (probably overkill!)
attempt a connection with a generous timeout, mysql -S/tmp/mysql.sock --connect-timeout=# --user=youruser --password
https://stackoverflow.com/a/21189440/4036945 (wait .. sleep using curl to hit up a webservice that in turn connects to the db: maybe your app has a 'status' page? and maybe it waits a while and retries a db connection before it returns to the http client)
https://unix.stackexchange.com/a/5279 (wait .. sleep using netcat, netstat and lsof, but these i think will all require sudo unless you start mysql from within the ci framework, in which netstat from the ci framework should provide the info)
tricky question and I don't know if SO is the good space (maybe AskUbuntu ? or SuperUser ?)
I've set my Lampp on my ubuntu in /opt/lampp/
Problem, when I need to call direct bin as mysqldump, I end up calling the default installed one on my ubuntu, not the one linked to my lampp :
$ mysqldump --user=root test
mysqldump: Got error: 2002: Can't connect
to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
when trying to connect
As you can see, it check for /var/run.
If I want to use the good one, I should specify the path :
$ /opt/lampp/bin/mysqldump --user=root test
-- MySQL dump 10.13 Distrib 5.6.21, for Linux (x86_64)
I could use the full path in my PHP call, but my PHP prod server will then not work.
How can I set the Lampp bin as default to be used by php with exec('mysqldump')?
You really have several choices to do what you want.
You could create a configuration file that depends on your environement (local, dev, preprod, prod ...). This file may declare an array of configurations, one of which is the path of the executable you need. Your php code will know the environment by checking a global variable, for instance $_SERVER, which can be set in your web server's vhost file. I think that's the clean way of doing.
You could hardcode a path for you executable (let's say /home/www/mysqldump) and create a symbolic link with ln -s (if I remember right, or check the man page) between your environment's executable /opt/lampp/bin/mysqldump and /home/www/mysqldump. You have to prepare all your environments that way. I think it's a bit ugly but it's quick.
I am sure there are tons of other solutions.
A script to turn xdebug On works but I cannot figure out out to create a shortcut to run it. If I open administrator PowerShell in C:\Users\George\Desktop\Development\Config Files, the command .\PHPxDebugOn will restart Apache with the modified php.ini. (There's also a PHPxDebugOff.ps1 to turn xdebug off.) Clicking on the shortcut (with Run as administrator ON) just flashes a black screen but no change to Apache.
script:
$iniFile = "C:\Users\George\Desktop\Development\Config Files\php.ini"
$xFile = "C:\Users\George\Desktop\Development\Config Files\xdebug.ini"
$phpIniFile = "C:\PHP\php.ini"
get-content $iniFile, $xFile | set-content $phpIniFile
C:\Apache24\bin\httpd -k restart
shortcut target:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -file "&C:\Users\George\Desktop\Development\Config Files\PHPxDebugOn.ps1"
The problem is in the shortcut target.
Removing the & symbol should resolve the script not running, provided the path is correct.
PowerShell exits without attempting to run the script if the target file in the shortcut is invalid in any manner. Unless everything in the command can be evaluated/parsed/retrieved, the default behavior is to stop everything and report the error. That explains why the window disappeared, even with the -NoExit parameter specified. PowerShell does present the error in the brief moment that window is visible. Screen refresh rates and processor speeds being what they are, screenshots were a bit of a challenge to catch.
Sample 1:%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoExit -file "&C:\scripts\hello.ps1"
Sample 2:%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoExit -file "C:\scripts\hello.ps2"
Sample 3(successful):%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoExit -file "C:\scripts\hello.ps1"
Notes:
Repro environment: Windows 7 Enterprise with Powershell 5.0 April 2015 preview
The .ps2 file extension may be valid on some systems
You can skip loading PowerShell profiles by using the -NoProfile parameter
File must be the last parameter in the command, because all characters typed after the File parameter name are interpreted as the script file path followed by the script parameters
Seeing as my comment is, according to the OP, a better approach to the problem, I'll post it here as an answer:
What I'd do is create a second virtual host that points to the same source, but loads separate php.ini files to enable xdebug on that vhost. That way, you can simply use http://local.project.dev and http://local.project.debug to run the same code with xdebug enabled. This way, you don't have to restart apache each time you want to use xdebug to step through the code.
I use composer on a network where the only way to access the internet is using HTTP or socks proxy. I have http_proxy and https_proxy environment variables. When compose tries to access HTTPS URLs I get this:
file could not be downloaded: failed to open stream: Cannot connect to HTTPS server through proxy
As far as I know the only way to connect to a https website is using a connect verb. How can I use composer behind this proxy?
If you are using Windows, you should set the same environment variables, but Windows style:
set http_proxy=<your_http_proxy:proxy_port>
set https_proxy=<your_https_proxy:proxy_port>
That will work for your current cmd.exe. If you want to do this more permanent, y suggest you to use environment variables on your system.
If you're on Linux or Unix (including OS X), you should put this somewhere that will affect your environment:
export HTTP_PROXY_REQUEST_FULLURI=0 # or false
export HTTPS_PROXY_REQUEST_FULLURI=0 #
You can put it in /etc/profile to globally affect all users on the machine, or your own ~/.bashrc or ~/.zshrc, depending on which shell you use.
If you're on Windows, open the Environment Variables control panel, and add either a system or user environment variables with both HTTP_PROXY_REQUEST_FULLURI and HTTPS_PROXY_REQUEST_FULLURI set to 0 or false.
For other people reading this (not you, since you said you have these set up), make sure HTTP_PROXY and HTTPS_PROXY are set to the correct proxy, using the same methods. If you're on Unix/Linux/OS X, setting both upper and lowercase versions of the variable name is the most complete approach, as some things use only the lowercase version, and IIRC some use the upper case. (I'm often using a sort of hybrid environment, Cygwin on Windows, and I know for me it was important to have both, but pure Unix/Linux environments might be able to get away with just lowercase.)
If you still can't get things working after you've done all this, and you're sure you have the correct proxy address set, then look into whether your company is using a Microsoft proxy server. If so, you probably need to install Cntlm as a child proxy to connect between Composer (etc.) and the Microsoft proxy server. Google CNTLM for more information and directions on how to set it up.
If you have to use credentials try this:
export HTTP_PROXY="http://username:password#webproxy.com:port"
Try this:
export HTTPS_PROXY_REQUEST_FULLURI=false
solved this issue for me working behind a proxy at a company few weeks ago.
This works , this is my case ...
C:\xampp\htdocs\your_dir>SET HTTP_PROXY="http://192.168.1.103:8080"
Replace with your IP and Port
on Windows insert:
set http_proxy=<proxy>
set https_proxy=<proxy>
before
php "%~dp0composer.phar" %*
or on Linux insert:
export http_proxy=<proxy>
export https_proxy=<proxy>
before
php "${dir}/composer.phar" "$#"
iconoclast's answer did not work for me.
I upgraded my php from 5.3.* (xampp 1.7.4) to 5.5.* (xampp 1.8.3) and the problem was solved.
Try iconoclast's answer first, if it doesn't work then upgrading might solve the problem.
You can use the standard HTTP_PROXY environment var. Simply set it to the URL of your proxy. Many operating systems already set this variable for you.
Just export the variable, then you don't have to type it all the time.
export HTTP_PROXY="http://johndoeproxy.cu:8080"
Then you can do composer update normally.
Operation timed out (IPv6 issues)#
You may run into errors if IPv6 is not configured correctly. A common error is:
The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out
We recommend you fix your IPv6 setup. If that is not possible, you can try the following workarounds:
Workaround Linux:
On linux, it seems that running this command helps to make ipv4 traffic have a higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
Workaround Windows:
On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).
Workaround Mac OS X:
Get name of your network device:
networksetup -listallnetworkservices
Disable IPv6 on that device (in this case "Wi-Fi"):
networksetup -setv6off Wi-Fi
Run composer ...
You can enable IPv6 again with:
networksetup -setv6automatic Wi-Fi
That said, if this fixes your problem, please talk to your ISP about it to try and resolve the routing errors. That's the best way to get things resolved for everyone.
Hoping it will help you!
according to above ideas, I created a shell script that to make a proxy environment for composer.
#!/bin/bash
export HTTP_PROXY=http://127.0.0.1:8888/
export HTTPS_PROXY=http://127.0.0.1:8888/
zsh # you can alse use bash or other shell
This piece of code is in a file named ~/bin/proxy_mode_shell and it will create a new zsh shell instance when you need proxy. After update finished, you can simply press key Ctrl+D to quit the proxy mode.
add export PATH=~/bin:$PATH to ~/.bashrc or ~/.zshrc if you cannot run proxy_mode_shell directly.
When I try to export my database through MySQL Workbench remotely from localserver,
I am getting some below version error:
mysqldump Version Mismatch [Content] mysqldump.exe is version 5.5.16, but the MySQL Server to be dumped has version 5.6.10-log. Because the version of mysqldump is older than the server, some features may not be backed up properly. It is recommended you upgrade your local MySQL client programs, including mysqldump to a version equal to or newer than that of the target server. The path to the dump tool must then be set in Preferences -> Administrator -> Path to mysqldump Tool
I am trying to find a solution - I searched for solution on google but couldn't find a good answer to solve the issue.
Does anyone know, how to fix this issue in MySQL Workbench?
Go to: Edit -> Preferences -> Administrator -> Path to Mysqldumptool:
Look for file mysqldump.exe in your MySQL Server installation folder (it could be: mysql/bin/).
Then click it, and OK. After that try to do the backup.
Fortunately, although not obvious, there is a fairly straightforward solution. You just need to update the mysqldump.exe. The up to date version of the .exe file can be found in. To solve the issue just go to Edit->Preferences->Administrator, and browse the following path
C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqldump.exe
grab this file and replace it at the Path to mysqldump tool textbox
There may be the following path is set before the above mentioned before, so just replace it with the newer one
C:\Program Files\MySQL\MySQL Workbench CE 5.2.47\mysqldump.exe
The paths may be slightly different for you, but the solution remains the same.
In some OS(64bit), there are two folders
C:\Program Files (x86)\MySQL
and
C:\Program Files\MySQL
But you have to go for C:\Program Files\MySQL
Hope it will help :)
In Linux-based like Ubuntu, Edit > Preferences... > Administration (tab), set "Path to mydqldump Tool" to /usr/bin/mysqldump (most likely by default that's where it suppose to be).
If you're not sure, you can try to find where is the mysqldump located by running the following command in terminal:
locate mysqldump
The message says you need a newer mysqldump tool. One that matches the server you want to dump from. So depending on the platform you are running get a copy of the mysqldump tool from a server installation that has a recent version. Each server comes with a mysqldump tool. So it should be easy to get a copy.
Put the tool in a location where it has a persistent home, but does not conflict with other instances, and point MySQL Workbench at it (as the message says).
This occurs when the version of your mysql workbench is different than that of your mysql server. Solution to this is to use mysqldump.exe having version same as that of your server for taking the export/dump.
Steps :
Download the mysql zip of the same version as your server. (eg. mysql-5.7.25-winx64.zip)
Inside this zip you will find mysqldump.exe under bin folder.
Open the Mysql workbench. Go to Edit -> Preferences -> Administration.
Now, in Path to mysqldump Tool :, give the path of this downloaded mysqldump.exe
I was trying to solve this issue with the default mysqldump using Edit > Preferences... > Administration (tab), and setting from /usr/bin/mysqldump which did not work.
I saw that XAMPP server has a mysqldump file too which worked fine! Generally, you can find it in /opt/lampp/bin/mysqldump (for Debian and similar) so you can use this path in your preferences inside workbench.
I did take an archive for mysql version of need from here https://downloads.mysql.com/archives/community/
And used from there mysqldump. It helped for me.
On my Mac, (running latest Mac OS Sierra), I changed the path of mysqldump to /Applications/XAMPP/xamppfiles/bin/mysqldump, and that solved the problem. Previously, the path was set to a different version (older version) of mysqldump. So, you need to get the newest version of mysqldump.
The solution that worked for me is the following:
enter the page https://www.pconlife.com/viewfileinfo/mysqldump-exe/
there is a list of mysqldump.exe files, they must download the version that matches the one that appears in the error.
then go to the folder where mysql is installed usually
C: \ Program Files \ MySQL \ MySQL Workbench 8.0 CE
There they put the downloaded file, and they give it replace.
now open MySQL they will change the path that appears in:
Preferences> Administration> Path to mysqldump tool:
by the address where the replaced file was
that's all
As these answers are not totally clear for Mac users this is where I found my MySQLDump file:
Applications > MAMP > Library > bin > mysqldump
A quick search of 'mysqldump' should locate this.
I followed the above answers and go to:
Preferences > Administation > Path to mysqldump Tool:
This was my path in there now: /Applications/MAMP/Library/bin/mysqldump
wb_admin_export.py (used by mysqldump) looks at PATH variable to find mysqldump and get version number. make sure its mysqldump from mysql bundle, not mysql workbench...
Mac user here: I had this problem after updating MySQLWorkbench. Tried everything.... at last, I downloaded the old version back and downgraded MySQLWorkbench. Worked flawlessly.
For Mac users, it works only after restarting Mysql Workbench, after setting Path to Mysqldumptool in settings (Edit - Preferences - Administrator ).
None of the other answers here has worked for me, so I'll post another way that has fixed mine(I'm using Windows WSL Ubuntu 18.04).
TL;DR: check if you have the line local_infile=1 in the configuration file of your MySQL and change it to loose-local-infile=1 or comment it out altogether if you don't need it now and then restart your MySQL Workbench.
Further Explanation: I closed MySQL Workbench and opened up my terminal and ran mysqldump --version and it gave me this error: mysqldump: [ERROR] unknown variable 'local_infile=1'., I realized that I'd added something to the /etc/my.cnf file previously in order to import some data into a database using a local file, but as it turns out, some other MySQL tools (such as mysqldump, probably) do not understand this line well, so I commented it out and then mysqldump --version works fine and gives the correct version number without any other issues. Now I open the MySQL Workbench once again and this time it's working fine.
HTH.
If none of the above solutions worked the version of mysqldump can be hardcoded in wb_admin_export.py
def get_mysqldump_version():
#path = get_path_to_mysqldump()
#if not path:
# log_error("mysqldump command was not found, please install it or configure it in Edit -> Preferences -> Administration")
# return None
#
#output = StringIO.StringIO()
#rc = local_run_cmd('"%s" --version' % path, output_handler=output.write)
#output = output.getvalue()
#
#if rc or not output:
# log_error("Error retrieving version from %s:\n%s (exit %s)"%(path, output, rc))
# return None
#
#regexp = ".*Ver ([\d.a-z]+).*"
#if ("Distrib" in output):
# regexp = ".*Distrib ([\d.a-z]+).*"
#
#s = re.match(regexp, output)
#
#if not s:
# log_error("Could not parse version number from %s:\n%s"%(path, output))
# return None
#
#version_group = s.groups()[0]
#major, minor, revision = [int(i) for i in version_group.split(".")[:3]]
#return Version(major, minor, revision)
return Version(5, 7, 30)
Only this worked for me: Workbench on windows and Mysql server on a remote linux.
I had to make a local copy of my remote database and was facing MySQLWorkbench´s version problems. In order to avoid reinstall MySQLWorkbench to adapt to the remote database version, I did next:
I exported my database from the remote server into /home/my-user/ folder (on remote server) using ssh:
root#bananapi# mysqldump -u root -p my-incredible-password > /home/my-user/database-dump-18-set-2020.sql
Having the sql script in /home/my-user/ remote directory I download it in my local folder using scp command:
my-user % scp root#remote-server-ip-address:/home/my-user/database-dump-18-set-2020.sql /Users/my-mac-user/tmp/
The I just had to open the sql script file using my MySQLWorkbench and import the data in my local database. I hope this can help somebody.
A possible solution is to create a script that runs mysqldump with the flag --column-statistics=0, then configure Workbench to point to the script:
#ECHO OFF
"C:\Program Files\MySQL\MySQL Workbench 8.0 CE\mysqldump.exe" %* --column-statistics=0
For WordPress data dumps (in my case it uses MySQL v 5.7.39) I downloaded the respective version of Workbench (v6.3.10) and installed it in a different directory. Then configured MySQL workbench v 8.0.28 to point the paths to the mysqldump tool and MySQL tool to Workbench v6.3.10 app internal paths by copying/pasting the routes.
Then exporting was successful.