I've enjoyed Homestead for years and today noticed a very appealing feature that I've never used before.
https://laravel.com/docs/7.x/homestead#database-snapshots says:
Homestead supports freezing the state of MySQL and MariaDB databases
and branching between them using Logical MySQL Manager. For example,
imagine working on a site with a multi-gigabyte database. You can
import the database and take a snapshot. After doing some work and
creating some test content locally, you may quickly restore back to
the original state.
...
A common workflow looks like the following:
Import a database into the default master lmm branch.
Save a snapshot
of the unchanged database using sudo lmm branch prod-YYYY-MM-DD.
Modify the database.
Run sudo lmm merge prod-YYYY-MM-DD to undo all
changes.
Run sudo lmm delete <branch> to delete unneeded branches.
This tool sounds really useful, but I'm having trouble following those instructions. Here is what I've tried and the results:
sudo lmm status
Active snapshot:
Database snapshots:
master
2.70% used by MySQL databases.
sudo lmm branch beforeImports
df: '': No such file or directory
Logical volume name "" is invalid.
Run `lvcreate --help' for more information.
mount: /homestead-vg/beforeImports: special device /dev/homestead-vg/mysql-beforeImports does not exist.
mount: /homestead-vg/beforeImports: special device /dev/homestead-vg/mysql-beforeImports does not exist.
mount: /homestead-vg/prod-YYYY-MM-DD: special device /dev/homestead-vg/mysql-prod-YYYY-MM-DD does not exist.
mount: /homestead-vg/beforeImports: special device /dev/homestead-vg/mysql-beforeImports does not exist.
sudo lmm checkout master
is the currently active database.
Setting /homestead-vg/master as the active database.
rm: cannot remove '/var/lib/mysql': Is a directory
ln: failed to create symbolic link '/var/lib/mysql/master': File exists
I'm using: Windows 10, Vagrant 2.2.7, Virtualbox 6.1.2, Homestead v10.2.0.
What am I doing wrong?
P.S. I looked at https://github.com/Lullabot/lmm/blob/ubuntu-18.04/functions.sh#L5 (which I think is what Homestead is using), and then I ran sudo echo `readlink /var/lib/mysql`, and it printed a blank line. But sudo ls -lah /var/lib/mysql shows lots of files. I clearly don't know what I'm doing and would appreciate any help.
P.P.S. I also see https://github.com/laravel/homestead/issues/1112 but do not understand.
There was a bug that prevented LMM from working with MySQL 8: https://github.com/laravel/homestead/issues/1383
Related
While trying to spin up a server using docker-compose I have an issue when I try to downgrade or upgrade the mysql image. As I am just trying to identify the right mysql/maraidb version I'm not concerned about the data at the moment.
I've been getting the following error
"Unsupported redo log format. The redo log was created with MariaDB 10.6.5."
I am unable to delete the logs ib_logfile0 ib_logfile1. How do I successfully upgrade/downgrade mysql when it is giving such an error?
When the upgraded/downgraded version of the mysql/mariadb is spun up, you can't delete the ib_logfile0 ib_logfile1 log files because the new version won't start and therefore you can't even docker exec into it.
Since data retention is not a priority, the solution here is to remove the specific container or any stopped containers and all unused images (not just dangling images), add the -a flag to the command.
docker system prune -a
Also this issue may happen if you are moving between two different project folders. in that case, try to identify the volumes that may have used the same image and delete them where necessary
docker volume rm volume_name volume_name
More on how to remove stopped images:
https://www.digitalocean.com/community/tutorials/how-to-remove-docker-images-containers-and-volumes
I have a Postgres permissions problem, every time i brew install postgres it does so as root user resulting in permissions denial on initdb, createdb and or anything else i try.
I sudo chown the ownership of /usr/local/var/postgres and it seems to change and allow me manual entry into the directory from cmd line, which then only consists of a server.log file listing the error:
postgres cannot access the server configuration file "/usr/local/var/postgres/postgresql.conf": No such file or directory
I then go to initdb and it returns:
The files belonging to this database system will be owned by user "jamesbkemp".
This user must also own the server process.
The database cluster will be initialized with locale "en_GB.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
initdb: directory "/usr/local/var/postgres" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/usr/local/var/postgres" or run initdb
with an argument other than "/usr/local/var/postgres"
I then go back to look at /usr/local/var/postgresand the owner has changed back to root. I really am at a loss after many hours on this as to what's going on. Any ideas folks?
Postgresql install as non root is a pain if not impossible, because it was not designed this way: it is a multi-user service.
The same thing here: apache2 as non-root - you would have to build the server yourself changing the configuration a lot.
Let me add that for an experienced datacenter operator this is a strange idea, like driving a race car in your appartment.
I am new to Vagrant and get the following error on vagrant up or vagrant ssh:
The private key to connect to this box via SSH has invalid permissions
set on it. The permissions of the private key should be set to 0600, otherwise SSH will
ignore the key. Vagrant tried to do this automatically for you but failed. Please set the
permissions on the following file to 0600 and then try running this command again:
[...]/.vagrant/machines/default/virtualbox/private_key
I have run:
$ sudo chmod 666 [...]/.vagrant/machines/default/virtualbox/private_key
I also tried (600, 777) but still get the same error.
Please can someone tell me what is wrong and how to fix it?
I just had this issue, and I worked around it moving the private_key file to another place, changing its permission, and then creating a symbolic link at the original place.
So,
$ mv [...]/.vagrant/machines/default/virtualbox/private_key /some/path/where/you/can/change/permissions
$ ln -s /some/path/where/you/can/change/permissions [...]/.vagrant/machines/default/virtualbox/private_key
If you're using the Windows Subsystem for Linux (WSL), this error can occur when you're trying to vagrant up in a directory that is outside the user's home directory.
From the Vagrant docs:
If a Vagrant project directory is not within the user's home directory on the Windows system, certain actions that include permission checks may fail (like vagrant ssh). When accessing Vagrant projects outside the WSL Vagrant will skip these permission checks when the project path is within the path defined in the VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH environment variable.
Changing the VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH to the current working directory (or a directory above it) can fix this. For example, if your project is in /mnt/c/www, then set the environment variable accordingly:
export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/www"
I got the same error now. The problem happened because i was trying to do vagrant up in an NTFS partition, just like the error message tell me.
So i created an directory link in my ext4 partition and an simbloc link in my NTFS to solve this. Works Fine now!
Thanks!
I had this same problem and turns out chmod seems to be working fine but is not actually changing permissions, my files where at an NTFS partition, try changing them to an ext4 or similar.
Got this error using otto (which layers on vagrant)
It is def filesystem related, have a fat partition to allow use with windows (used to, no longer). When the permissions couldn't be set on the partition I just copied the whole directory over to my user directory (as I always should have).
Was using git so I just reset to head to get back to my starting place... re-ran:
otto compile
otto dev
up and running now.
I restored my Mac form a Time Machine backup, and now I can't check files into my svn repo.
I have tried svnadmin recover, but it fails:
svnadmin: Can't open file 'WriteAssist/db/write-lock': Permission denied
The directory is owned by the "admin" user that I set up for bootstrapping the machine. My current user is "andersprivat".
Should I just chown the entire tree? Doing a chmod 777 would presumably work, but seems like a big security hole.
In the end svnadmin recover appeared to do nothing at all for me.
I ended up having to chmod -R 777 all the files to be allowed to check in at all, then manually handling all in-flight issues. Did not leave me loving svn any more than I already did. When it works it's great, but getting it up when it has stumbled is a b*tch.
I've managed to mess up my MySQL database (on Mac OS X 10.5) and need help recovering!
I tried to add an index to a fairly large table (190 million records) and in the course of this, I ran out of disk space. Subsequently realized that the partition with the data directory is too small and so I need to move it.
Initially I thought that I would just copy the data directory to another location, then bung a symlink in place of the original data directory.
BUT it refuses to move!
sudo cp -r /usr/local/mysql/data .
cp: ./data: Permission denied
(I have stopped the mysqld process before attempting this move)
Help!
This isn't a mysql question, but rather an OS question.
I would guess that you either don't have permission to write to the current directory, or there's already a directory there named 'data' that you don't have permission on, etc.
In my experience, MySQL doesn't like running out of disk space at all. Make sure the last records are OK after you bring the engine back up.
Also, don't use the symlink - change the mysql config. In Unix, this would be the 'datadir' setting in /etc/my.cnf.