I have a broken installation of Ubuntu 14.04 - it won't boot, but I won't say anymore about that because that's not what I'm asking about really. I have a MySQL database (created using v5.5) on the broken Ubuntu installation and I need that data. I can get at the raw MySQL database files by mounting the broken installation onto another machine.
I actually need the database to be imported into a MySQL v5.1 installation. I tried copying the raw database files (e.g. the directory at /var/lib/mysql/dbname) into the same directory on the working OS installation. At first, it seemed like it worked, I can see the database, I can use it and I can list the tables. But it turns out that even though I can see the tables in the db, any attempts to describe or use them in any way give the 'table doesnt exist` error.
Ideally, I'd love to be able to use msqldump and then import the database the proper way, but how can I get a dump of the database if it's not part of the MySQL installation (remember, I can't boot into the installation, it's broken).
Of course, mysqldump is the most preferable solution, but if it's not possible to use that utility with the raw database files as input, then I'm willing to try anything that might work.
Of course the first thing you should do is to install the same version of MySQL as the original - if you're directly using the raw data files, keeping things as identical to the original as possible is a must! The same applies to paths, make sure the new installation and data files are placed in the same directory path that they were originally.
Once you have this, you can mysqldump the tables and use that to import into a clean, new installation.
Related
I've done a bit of googling and haven't been able to find any documentation on this, but I need to upgrade my Seeddms (Document Management System) server from 5.1.25 to 6.0.19.
I am running a Linux Lamp 4.19.0-19-amd #1 SMP Debian 4.19.232-1 (2022-03-07) with a Seeddms web server on it.
I tried copying the contents of the .gz download file of the latest version over my current /var/www/html/dms/ folder and it didn't work, I did a similar thing to update my dokuwiki site so I thought I'd give it a try here.
I am still new to Linux so any advice would be greatly appreciated!
I was able to find the solution, in the seeddms-quickstart-x.x.x/seeddmsxxx/seeddms-x.x.x/doc/README.Install.md.
Here is what is says on upgrading versions if anyone has trouble with this as well. Make sure your server meets the requirement as well.
UPGRADING FROM A PREVIOUS VERSION OF SEEDDMS
As SeedDMS is a smooth continuation of LetoDMS there is no difference
in updating from LetoDMS or SeedDMS.
You have basically two choices to update SeedDMS:
you install a fresh version of SeedDMS and copy over your data and configuration
you replace the software in your current installation with a new version
The first option is less interuptive but requires to be able to set up a second
temporary SeedDMS installation, which may not be possible, e.g. because of storage
limitations. It can be the only option if you change servers.
The first update procedure is only needed if the version changes on the minor
or major version number. Changes in the subminor version number will never
include database changes and consequently it is sufficient to use the existing
data directory and database with the new version. Choose the second update
option in this case.
In both cases make sure to have a backup of your data directory, configuration
and database.
Fresh installation and take over of data
The first update option is to set up a new instance of SeedDMS and once
that is running take over the data from your current (old) instance.
just do a fresh installation somewhere on your web server and make sure it
works. It is fine to use
SQLite for it, even if your final installation uses MySQL.
replace the data directory in your new installation with the data directory
from your current installation. Depending on the size of that directory (and
whether the new installation is on a new server or the old server) you
may either copy, move or place a symbolic link. The content of the data directory
will not be changed during the update. Its even perfectly save to
browse through your documents and download them after finishing the
update. The data directory will not be modified until you actually modify
documents.
copy over the configuration settings.xml into your new installation. This will
effectively make your new installation use the data from your old installation,
because all paths are still pointing to the old installation.
if you use mysql you could as well make a copy of the database to make sure
your current database remains unchanged.
modify the settings.xml to fit the environment of the new installation.
This will mostly be the
httpRoot, the paths to the installation directory and possibly the database
connection.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
Upgrading your current installation
Instead of setting up a new installation, you may as well replace the php files
in your current installation with new versions from the quickstart archive.
get the SeedDMS quickstart archive seeddms-quickstart-x.y.z.tar.gz and
unpack it somewhere on your disc.
copy the directory seeddms-x.y.z from the unpacked archive into your
current installation and make the link seeddms point to this new directory.
copy the directory pear from the unpacked archive into your current
installation, replacing the existing directory. Make a backup of pear before
the replacement if you want to ensure to be able to go back to your old version.
you may compare your conf/settings.xml file with the shipped version
conf/settings.xml.template for new parameters. If you don't do it, the next
time you save the configuration the default values will be used.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
I am using postgresql-9.4 (port 5432) and postgresql-10.0 (port 5433) on my Linux machine (RHEL 7.4). Postgresql-9.4 was installed using yum repository and Postgresql-10.0 was installed using source in different partitions.
I have taken a backup of db (dtbase.backup) on Postgresql-9.4 using it's pg_dump and trying to restore this on Postgresql-10.0 using it's pg_restore.
While doing this, I am getting below error:
pg_restore: [archiver] unsupported version (1.13) in file header
I have checked different forums but unable to find the solution. Any help would be highly appreciated.
You'll have to upgrade your PostgreSQL v10 to 10.3 so that you have commit b8a2908f0ac735da68d49be2bce2d523e363f67b:
Avoid using unsafe search_path settings during dump and restore.
Historically, pg_dump has "set search_path = foo, pg_catalog" when
dumping an object in schema "foo", and has also caused that setting
to be used while restoring the object. This is problematic because
functions and operators in schema "foo" could capture references meant
to refer to pg_catalog entries, both in the queries issued by pg_dump
and those issued during the subsequent restore run. That could
result in dump/restore misbehavior, or in privilege escalation if a
nefarious user installs trojan-horse functions or operators.
This patch changes pg_dump so that it does not change the search_path
dynamically. The emitted restore script sets the search_path to what
was used at dump time, and then leaves it alone thereafter. Created
objects are placed in the correct schema, regardless of the active
search_path, by dint of schema-qualifying their names in the CREATE
commands, as well as in subsequent ALTER and ALTER-like commands.
Since this change requires a change in the behavior of pg_restore
when processing an archive file made according to this new convention,
bump the archive file version number; old versions of pg_restore will
therefore refuse to process files made with new versions of pg_dump.
Security: CVE-2018-1058
Your 9.4 installation already uses archive format 1.13, which your v10 installation does not yet understand.
Besides, you should always use pg_dump from the higher PostgreSQL version to upgrade a database.
I'm quite new in the InstallShield stuff, I took this project from a leaving co-worker. However, here's my problem:
I was trying to update a MySQL Server with the setup from 5.7.17 to 5.7.19, which works great most of the times.
I got the feature "MySQL", splitted in "MySQL Data" (includes the performance_schema and mysql database), "MySQL Service" (Service batch files) and "MySQL Binaries" (the files).
For the update, I just changed the binaries by the new one and left the rest. All features are selected and my log tells me, that it installs all files which it hasn't installed by now, leaving the existing files untouched. As this is an update, it seems correct to me.
But sometimes, at the end of the setup process, it uninstalls almost anything of my MySQL Feature again; the databases, the batch files and almost any core file which wasn't changed by the setup before. But why is that and how can I stop my setup from do so?
Kind regards
I think what you're describing is that your file containing the data is not getting updated. Since this type of file cannot be versioned, that's what Windows installer uses to determine whether or not to upgrade the file, you will need to mark the component containing this file to Always Overwrite. Check out the MS docs for the Component table for how to do this with the Attributes field.
You may want to check the conditions on the components in question. Also, check the install sequence to see if it is calling uninstall out of sequence.
My colleague gave me a mysql.sql.xz in 80mb.
Exported from MySQL 5.6.26
I setup MySQL 5.6.28 in ubuntu 14.04, it only imports partial and broken, syntax error, as I m not able to unzip the files, so i only guess it reads partial SQL, where SQL not correctly ended.
I tried MariaDB 10 and it has the same problem.
I do unxz and only get part of the SQL file, and the last SQL in the file is incomplete.
I tried mysql.com and installed MySQL 5.6.29. It successfully dump in the .xz file.
Can anyone points out what possible problem here?
I have re-install quite many times now, the only working result is get the repo from mysql.com
Thanks in advance
If the file is truncated then that is the cause of your problem, right? It really sounds like you have an issue in transferring the file rather than any thing incorrect at either database instance
I created neo4j database using cypher queries through browser and some python (py2neo) routines.
Now, I have to transfer this database to another neo4j instance on my Linux desktop.
What I did-
Zip the contents of folder default.graphdb.
Unzipped the contents of the zip file to data/graph.db in my linux installation.
Also the user:pass of the database are same.
But when I goto the browser, I can't find any of that data. The directory does point to the folder that I extracted to (/home/goelakash/neo4j-community-2.3.0/data/graph.db).
How do I get that database?
EDIT - messages.log
https://drive.google.com/file/d/0B3JPglmAz1b5ak1vRWR5Z0p5UVE/view?usp=sharing
The data files should be located directly in data/graph.db. So check e.g. if there is a file called neostore.nodestore.db. If so, check the permissions - the system user running Neo4j needs to have full recursive read/write permission on the graph.db folder.
Also make sure that you're using the same version of Neo4j on Windows and Linux (or upgrade the store following the reference manual).
For more insight attach the startup sequence form data/graph.db/messages.log.