First of all, I am not sure how I came to this state. I use mySQL5.7 and I recently upgraded few dependencies for my gradle project. After the upgrade it didn't like previous comments in my database migration files. By the way I didn't change database version. Some of the comments were made without a space like bellow and it was fine before. If I add spaces after '--' it works but it's an issue with other environments to which
migration is already applied since migration files checksum is changed. Could anyone suggest me a solution? I initialize my local environment frequently and I need to make this work for all environments.
--My comments start here
Your best option is to fix your scripts, so that they contain valid MySQL syntax and then run Flyway's repair command to realign the checksums.
Related
Godaddy is forcing old servers offline and I have no choice but to migrate my old mediawiki service to a new server.
I had to maintain the old versions due to use of extensions which I fear are either gone or different now.
Here are the relevant versions:
Source: mediawiki 1.14.0, PHP 5.1.6 (apache2handler), MySQL 5.0.77
Target: mediawiki 1.32.0, PHP 7.2.15, MySQL 5.7.25, ICU 60.2
I have copies of all contents of /var/lib/mysql/ from the old server copied to the new one in a backup directory, and I have mysql dumps copied over too.
Is it possible to simply put the database tree from Source into Target under a different name and then modify LocalSettings.php?
If not, can the mysql dump be restored to do the job?
Extensions have changed and I will have to review hundreds of pages to check for problems.
Any advice on how to do this with the least problems is welcome.
Also, I might consider hiring a contractor to review the task and supervise my work. It would have to be someone who has done migrations of this sort before, or someone with other clear sufficient experience.
The short answer to your question is, painfully. That's about a decade's worth of changes. There isn't any magic spell that will make applying them less hard than it sounds; you'll have to import the old database, run update.php, and prepare for debugging any errors that might occur as you will be using an upgrade path that few if any people have taken before you.
Alternatively, you might export the content (maintenance/dumpBackup.php existed in 1.14) and reimport into the new wiki, and accept losing and having to recreate everything that's not content or content history (like user records).
Is it possible to simply put the database tree from Source into Target under a different name and then modify LocalSettings.php?
Yes, although I'm not sure what you win by using a different name.
I was facing a similar issue. I can only strongly recommend to read the release notes for any version carefully, especially for database changes and changes on how skins and extensions are loaded in the LocalSettings.php. For example the way the skins work change around version 1.24 IIRIC.
Also, be sure to create a renamed copy of your 1.14 LocalSettings.php and create a fresh one during the upgrade via the installer, the old one will cause a multitude of exceptions. You may also need to run the database upgrade several times.
Also make sure you move your old 1.14 wiki installation to an extra folder and upload a fresh mediawiki installation, do not just overwrite your existing files in the 1.14 one with the new mediawiki version.
In the end, I went the long route and upgraded version by version first on a local XAMPP dump, then on the server after I identified all the issues for each version upgrade, checked the release notes for each version and made the required changes to my custom skins, replaced deprecated extensions etc.
Good luck.
Back in september '17 I installed an ejabberd-instance on a (debian 9-)server my dad still pays for, but is no longer using. The small circle of friends that initially used it, quickly grew and now there's a few hundred of us chatting away.
Time has come to update the ejabberd (I installed 16.09-4) because we want to stay secure and be able to enjoy all the latest whistles and bells. I thought some simple 'apt-get upgrade'-magic would do the trick, but boy, was I wrong.
I looked at the docs (Specific version upgrade notes) and tried to update to 17.03, by following the steps described there.
These updates fail miserably (missing links to /usr/sbin/ causing failure to to restart server after update. Adding symlinks does not help. I believe I chose to install to /opt/ last year, which would explain why).
Since I have some experience with MySQL and none whatsoever with Mnesia, I also decided in the beginning to add "default_db : SQL" in my ejabberd.yml file. I (wrongly) assumed all data would be stored in a MySQL-DB, and no longer in the Mnesia. This does not seem to be the case: I see all of the registered users in Mnesia (using ejabberdctl) but only part of the complete list in MySQL.
I guess my question is twofold:
What would be the most efficient way to update from 16.09-4 to the latest version ? (I am aiming for a solution without having to install a new ejabberd-instance on a different server and simply backing up and migrating the MySQL)
How can I avoid using Mnesia completely and only use MySQL ? And, related: How can I push all existing Mnesia-data into MySQL ?
What would be the most efficient way to update from 16.09-4 to the latest version ?
As you have some kind of confusion about what and where is installed, problems in links, paths, etc, I propose as "the most efficient" a solution that has many many steps, but at least will work whatever you have:
First handle the old one:
Find your config dir and mnesia spool (try 'ejabberdctl help')
Stop ejabberd
Move to a safe location your config dir and mnesia spool
Uninstall ejabberd and all ejabberd related files and dirs
Now comes the new one:
Install ejabberd in the way you prefer: Debian package, source, whatever
Let it start, so it creates default config files and minimal mnesia spool
You can even register an account, login, check it runs correctly
Find the new config dir and mnesia spool (maybe they are different paths due to different install process)
Stop ejabberd
And now recover your old information
Replace the new config dir with old one, and the new mnesia spool with your old one
Start ejabberd again, with old config and old mnesia. It may complain about useless or unknown options, it may also report it's updating the database schema.
If it at least starts, check you have all the users, and also update the config file in case there were renamed options...
Of course, there are easier and faster ways to update, but your special case requires special steps.
How can I avoid using Mnesia completely and only use MySQL ?
Why exactly do you want to avoid it at all costs? It's required for some stuff in ejabberd, like client sessions, internal routes, commands... Other stuff can be moved to MySQL, like roster, passwd, MUC, vcards...
And, related: How can I push all existing Mnesia-data into MySQL ?
You can configure many modules to use sql instead of mnesia, and then run the export2sql command that produces a *.sql file that you will import into your new MySQL database. After that, you can delete content of mnesia tables using the WebAdmin.
I've been working on making an auto-deployment system to make updating my django site easier, and it mostly works, but right now my database changes are screwy. I have the auto deployment run "makemigrations" "migrate" then "syncdb"
The trouble I have is when I run migrate, it tells me that my table already exists and can't be created. Previous answers have said to run "migrate --fake", but if I do this, it appears to think everything is up to date. The issue then is that I run "makemigrations" or "migrate" and it says no changes detected (even though there is a missing column from my database). I tried to run "sqlall" to figure out what it thinks the database should be, and it tells me that I have pending migrations. So I tried running "migrate" and it said no migrations exist.
How do I manage this? And in the future, what should I do for database migrations to troubleshoot/fix these problems?
Thanks
I fixed the problem. The issue stemmed from a misunderstanding of how Django migrations worked. Also, as per the comments, syncdb is no longer a command in manage.py.
The original issue was that I had been using a different database for deployment and then I switched and my migrations were out of sync from my development database, so I had to clear out both databases and migrations and start over with my data. Then I run makemigrations on my local machine and migrate there (for my dev DB). Then I upload to the server and have the fab script run migrate on the server production DB without calling makemigrations. This seems to have fixed the issue.
I normally migrate databases for wordpress installs using wp_sync_db plugin. It has never failed before. Now when I'm trying to migrate from my local development server to the live site it's giving the following error.
I've tried only migrating specific fields, but it always runs into an error, just the field will be different.
I've tried to manually import the database to the live site and that is also failing with this error:
I'm not a database expert, and this is really frustrating. I have about two days of work I'm trying to migrate to the live site and can't do it with these errors.
I've been working on trying to solve this issue for a few hours, but have got no where. I've tried deleting the fields mentioned in the error, but that changes nothing. I've tried about 1000 different variations and configurations and it just keeps failing.
Please some database expert step in and save me!
I have no idea about the wp_sync_db plugin, but the phpMyAdmin error comes from having an older version of MySQL on your host which doesn't support the utf8mb4_unicode_ci collation.
You could look for the "Database system or older MySQL server to maximize output compatibility with:" dropdown on the phpMyAdmin export page, then select MYSQL40 there, but you run the risk of losing data if you have multibyte characters stored in your database.
This support page has a good summary of the situation and strongly suggests that you make your local MySQL version match as closely to your hosted version as possible, but that seems like a harsh reality in which to develop. I'm not a WordPress expert, but I believe that if you export for MYSQL40 compatibility and check the resulting imported data for any flaws you should be relatively safe.
I'm working with MySQL databases.
To simplify the problem, let's say I have two environments : the local one (development) and the remote one (production mode).
In the database, I have some tables that contain configuration data.
How can I automate cleanly the delivery from the development mode to the production mode when I modify the database schema and the configuration tables content ?
For instance, I dot it manually by doing a diff between the local and remote databases. But, I find that method not so clean and I believe there is good practice allowing that.
This might be helpful in cases where you have multiple environments and multiple developers making schema changes very often and using php.. https://github.com/davejkiger/mysql-php-migrations
Introduce parameter "version" for your database. This version should be written somewhere in your code and somewhere in your database. Your code will work with database only if they have equal versions
Create a wrapper around your MySQL connection. This wrapper should check versions and if versions are not compatible, it should start upgrade.
"Upgrade" is a process of sequential applying the list of *.sql files with SQL commands, which will move your database from one state to another. It can be schema changes or data manipulation commands.
When you do something with database, do it only through adding new *.sql file and incrementing version.
As a result, when you deploy your database from development enviroment to production, your database will be upgraded automatically in the same way as it was upgraded during development.
I've seen LiquiBase http://www.liquibase.org/ a lot in Java environments.
In most of my projects I use sqlalchemy(a Python tool to manage db plus an ORM). If you have some experience(little more than beginner) with Python I highly recommend using it.
You can check this tool with a little help of that. This is also very useful for migrating your db to other rdbms(for example mysql to postgres or oracle).