Gzip compression

[lavmeiker]

Hi, cool script, works well. We've used rsync stuff for synching DB in the past, we try this new approach. Just an idea, what about gzip compression of the SQL file? Would speed up file transfer a lot, just my two cents. Thanks.

[lavmeiker]

Hi @ivomarino! That gzip idea sounds great. I'll add it to the features list for the next release.

[ivomarino]

Perfect, thanks @lavmeiker!

we also have another minor issue:

% cap staging wpcli:db:push

INFO[d422b7c1] Running /usr/bin/env wp db export /tmp/wpcli_database.sql on localhost
DEBUG[d422b7c1] Command: ( PATH=/usr/local/bin:$PATH WP_ENV=staging /usr/bin/env wp db export /tmp/wpcli_database.sql )
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host endeavour: wp exit status: 512
wp stdout: Nothing written
wp stderr: mysqldump: Got error: 1045: Access denied for user 'bedrock_wp'@'10.0.2.2' (using password: YES) when trying to connect
/usr/local/lib/ruby/gems/2.1.0/gems/capistrano-wpcli-0.0.5/lib/capistrano/tasks/wpdb.rake:43:in `block (5 levels) in <top (required)

as you can see it tries to connect to 10.0.2.2, which seems to be a Vagrant gateway IP, it should just use the IP of the staging server or it's hostname. Any ideas regarding this? Thanks.

[ivomarino]

maybe it's related to this: http://stackoverflow.com/questions/15512073/set-up-dhcp-server-ip-for-vagrant

[lavmeiker]

I have little experience with Vagrant but 10.0.2.2 is expected to be the IP of the server you want to deploy to. It's configurable in config/deploy/staging.rb.

[ivomarino]

it’s quite weird, it seems to look in .env for checking DB_HOST but if I put there
e.g. DB_HOST=192.168.80.2 he uses 192.168.80.1. Strangely :pull works fine, :push
has troubles.

% bundle exec cap staging wpcli:db:push
INFO[06ec9594] Running /usr/bin/env wp db export /tmp/wpcli_database.sql on localhost
DEBUG[06ec9594] Command: ( PATH=/usr/local/bin:$PATH WP_ENV=staging /usr/bin/env wp db export /tmp/wpcli_database.sql ) cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host endeavour: wp exit status: 512
wp stdout: Nothing written
wp stderr: mysqldump: Got error: 1045: Access denied for user 'bedrock_wp'@'192.168.80.1' (using password: YES) when trying to connect

[lavmeiker]

Have you tried using a hostname on DB_HOST instead of an IP?

2014-07-25 9:40 GMT-03:00 Ivo Marino notifications@github.com:

it’s quite weird, it seems to look in .env for checking DB_HOST but if I
put there
e.g. DB_HOST=192.168.80.2 he uses 192.168.80.1. Strangely :pull works
fine, :push
has troubles.

chinook:bedrock eim$ bundle exec cap staging wpcli:db:push
INFO[06ec9594] Running /usr/bin/env wp db export /tmp/wpcli_database.sql
on localhost
DEBUG[06ec9594] Command: ( PATH=/usr/local/bin:$PATH WP_ENV=staging
/usr/bin/env wp db export /tmp/wpcli_database.sql ) cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host endeavour:
wp exit status: 512
wp stdout: Nothing written
wp stderr: mysqldump: Got error: 1045: Access denied for user 'bedrock_wp'@'192.168.80.1'
(using password: YES) when trying to connect

On 25 Jul 2014, at 14:35, lavmeiker notifications@github.com wrote:

I have little experience with Vagrant but 10.0.2.2 is expected to be the
IP of the server you want to deploy to. It's configurable in
config/deploy/staging.rb.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[ivomarino]

yes, same problem.

[lavmeiker]

So, you use a hostname and it resolves into a wrong IP?
May be DNS problems?

2014-07-25 10:13 GMT-03:00 Ivo Marino notifications@github.com:

yes, same problem.

I.

Ivo Marino, B.Sc. IT
ivo.marino@ttss.ch
Tiger Team Software Solutions

On 25 Jul 2014, at 14:49, lavmeiker notifications@github.com wrote:

Have you tried using a hostname on DB_HOST instead of an IP?

2014-07-25 9:40 GMT-03:00 Ivo Marino notifications@github.com:

it’s quite weird, it seems to look in .env for checking DB_HOST but if
I
put there
e.g. DB_HOST=192.168.80.2 he uses 192.168.80.1. Strangely :pull works
fine, :push
has troubles.

chinook:bedrock eim$ bundle exec cap staging wpcli:db:push
INFO[06ec9594] Running /usr/bin/env wp db export
/tmp/wpcli_database.sql
on localhost
DEBUG[06ec9594] Command: ( PATH=/usr/local/bin:$PATH WP_ENV=staging
/usr/bin/env wp db export /tmp/wpcli_database.sql ) cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host
endeavour:
wp exit status: 512
wp stdout: Nothing written
wp stderr: mysqldump: Got error: 1045: Access denied for user
'bedrock_wp'@'192.168.80.1'
(using password: YES) when trying to connect

On 25 Jul 2014, at 14:35, lavmeiker notifications@github.com wrote:

I have little experience with Vagrant but 10.0.2.2 is expected to be
the
IP of the server you want to deploy to. It's configurable in
config/deploy/staging.rb.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
<
https://github.com/lavmeiker/capistrano-wpcli/issues/8#issuecomment-50143410>

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[ivomarino]

Yes

[ivomarino]

I think the bedrock_wp user has no permissions for dumping the DB, I'm checking: http://stackoverflow.com/questions/8658996/minimum-grants-needed-by-mysqldump-for-dumping-a-full-schema-triggers-are-miss

[ivomarino]

I confirm, when I do this as root MySQL user all is fine.

[lavmeiker]

I've just added the gzip feature this issue was about. Enjoy it! 😺

[ivomarino]

Also if this works perfectly:

mysqldump -h mysql.tt -u bedrock_wp -p bedrock_wp > /tmp/wpcli_database.sql

this still has problems:

% wp db export /tmp/wpcli_database.sql
mysqldump: Got error: 1045: Access denied for user 'bedrock_wp'@'192.168.80.1' (using password: YES) when trying to connect

when I put root user in .env it works also with wp db export, strange.

[ivomarino]

Thanks for the feature, I will check it out asap.

[ivomarino]

This is quite sure a wp-cli issue so I've asked there: wp-cli/wp-cli#1300

[lavmeiker]

+1

[ivomarino]

compression works great, thanks @lavmeiker:

INFO[ac2b22d3] Running /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz on www-ch.ttss.ch
DEBUG[ac2b22d3] Command: cd /var/www/vhosts/bedrock/current && ( PATH=/usr/local/bin:$PATH WP_ENV=production /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz )
INFO[ac2b22d3] Finished in 0.142 seconds with exit status 0 (successful).
DEBUGDownloading /tmp/wpcli_database.sql.gz 0.0%
DEBUGDownloading /tmp/wpcli_database.sql.gz 22.14%
DEBUGDownloading /tmp/wpcli_database.sql.gz 44.28%
DEBUGDownloading /tmp/wpcli_database.sql.gz 66.41%
DEBUGDownloading /tmp/wpcli_database.sql.gz 88.55%
INFODownloading /tmp/wpcli_database.sql.gz 100.0%

[ivomarino]

I'm using it with DB root credentials now, seems to be fine. No idea still why with non root DB auth it won't work. By the way, any suggestion on content synching? DB synch is creat but what about wp-uploads? We've using rsync in a Makefile since Capistrano, here's a short blog entry about this process we used: http://ttss.ch/new-cowboy-coding-style-development-workflow/ also: http://discourse.roots.io/t/capistrano-task-to-sync-uploads/1794

[lavmeiker]

The new version of the gem allows to rsync the uploads dir. Type cap -T to see how.

[ivomarino]

That's great, thanks. I'll check it asap.

[ivomarino]

Remember the non-root DB problem, think I fixed it: wp-cli/wp-cli#1300 (comment)

[ivomarino]

Errata corrige, the problem is still there I have to push as root.

[ivomarino]

rsync up- and download all fine, great!

[ivomarino]

a note on db:pull, when I dowload and sync the DB from PROD into local I need to run at least once: curl http://site.local/wp/wp-cron.php in order to refresh changes in the DB. In bedrock WP cron is disabled by default. Maybe you can trigger this after each DB pull or push.

[lavmeiker]

It seems a particular situation happening on your infrastructure. You can add that behaviour to your deploy.rb and run it after db operations.

[ivomarino]

No way to solve it with curl, it's not this. I'm using php5-apcu and varnish, I guess it's APC. After an amount of time AFTER the DB import from prod the site in local or stage works again. Same happens to prod when I push DB data there, I just get a white page then after so 10 minutes all is fine. I tip on some caching issue.