so while deploying into one test env (which has 2 instances of the server/API running), I started to receive ActiveRecord::ConcurrentMigrationError, after some digging I realize that my 2 instances run migrations separate and that causes the issue, after receiving this error no migrations are applied at all.
Checked using: rake db:migrate:status
I looked into the platform, and I found some info related to this error but I don't think are the proper solution, because the solution is to deactivate the lock introduced in rails 5 which can cause some weird issues during migrations (maybe I missed something if so, please let me know 👌).
Solution found
So the question:
Is there any way to solve this issue without deactivating the lock, or is that the proper solution (apart from only leave one of the instance instead of the 2 run the migration)?
Note: I would like to keep my migrations running automatically in both instances (just after the release) as usual.
Thx in advance 👍.
Related
We have a Spring boot application that has been in production for a while. We use Flyway to manage database migrations. I just upgraded to Spring boot 2.5.4 from 2.4.5 which brings with it an upgrade to Flyway 7.7.3.
When executing all the migrations in a fresh local environment, the migration now fails due to a syntax issue with this comment:
---*********************---
-- ** AUDITING TABLES ** --
---*********************---
I imagine this won't be an issue in environments which have already executed this migration but what is the best way to fix this for new environments with a fresh database given that the original file cannot be edited due to checksum comparison on migration?
My current versioning just includes a major version i.e. V2, V3 etc. My thinking is to get rid of V2 (the script with the issue) and introduce V2.1 which would be an exact copy of V2 with the erroneous comment section removed. I would then set both ignoreMissingMigrations and ignoreIgnoredMigrations to true
Does this sound like the right way to solve this?
Thanks in advance.
Changing the script and then executing flyway repair would be the ideal solution - this would rectify the checksums.
Assuming this option is not available for some reason (it would be helpful to know what that is in case we can fix it!), the above sounds correct. ignoreMissingMigrations means your old deployments won't object to V2 not being there, and ignoreIgnoredMigrations means they won't object to V2.1 being present. The downside is that these ignores may not be valid in the longer term - so they won't, for example, catch a later script that goes missing unintentionally.
On the Laravel Horizon dashboard, some job always shows as "paused":
How can I prevent this issue?
I had the same issue. It seemed to work and suddenly jobs would pause for no reason. I was using two applications with the same redis server, so conflicts would occur occasionally.
To resolve this you need to modify config/database.php and change the value of the key redis.default.database so the two (or more) applications don't mix up their keys.
So I have started the migration process from parse db to a mongolab db. The migration needed to be canceled at the verify stage. After pressing cancel, the migration tool is now stuck on the verify phase with no way to restart.
Has anyone else ran into this issue or have any ideas on how to restart the migration tool? Thanks ahead of time.
What I have attempted:
Removing and creating a new MongoLab DB
Multiple browsers
Logout/login
Parse Migration Tool Image
This issue seems to have been fixed on the parse side. But if it still happens, you have contact parse directly using the job id.
https://github.com/ParsePlatform/parse-server/issues/42
We discussed this here and basically in order to deal with migration
issues, we need you to individually report a bug through
parse.com/help. This allows each of you to get individual support,
from a team who can escalate issues, and for us to be able to ask up
front for specific information which will help us handle your issue.
We're exposing the 'job id' for the migration in the UI, and that is
something you should provide if you're having a problem.
Going to close this issue. For problems involving migration, or any
issues not specific to parse-server, please visit
https://parse.com/help and find the bug icon / "Something wrong?"
section to start the bug reporting flow.
I have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.
I am upgrading an existing magento website for 1.4 to 1.6.1.0.
I had dumped the existing database,
Copied all the required custom extension in the blank magento version 1.6.1.0
and after running the installation got the following error:
Error in file:
"/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php"
- SQLSTATE[HY000]: General error: 1025 Error on rename of './sales_flat_order' to './#sql2-3af-a7' (errno: 152)
How can I fix this issue?
Upgrading magento is very painful process. I suggest you to import-export data from old to new shop.
I just went through the same heartburn. I found that letting the page try to load until the script got an error or timed out and then trying again eventually worked. The upgrade script will attempt to start where it last stopped.
Before you do that, make a backup of you site and database. If it continually errors in the same spot, restore and try again.
These tips may help improve the odds of a quicker success:
Put the site in maintenance mode (by adding the maintenance.flag file
to the root directory) before starting.
Increase server and php timeouts by a very large amount (3-5minutes).
Cleanup temp and log database tables that you don't care about
(carefully, everybody has different needs here)
I tried several different methods and that is the only thing that worked. It took probably 10 reloads (waiting for a 3min timeout each time). In the end, everything upgraded correctly. No matter what method you choose, if you want to keep your store data, you will have to run the bulky db upgrade scripts that take forever.
I had similar issues when updating from 1.4.2 to latest.
I built a custom maintenance script included in my index.php that only allowes to access my ip. But the update process via shell replaced my index.php so it was accessible for everyone.
That was the cause that the final sql scripts where run by several clients and caused errors like "can't move table" etc. because those steps where already done.
--> Summing it up: Be sure that the site gets called only once, until the upgrade was successful!
The very best way to migrate magento in my opinion, is to import your entire db to an environment that you have your new magento. Then magento will run all scripts and updates and keep your data.
Maybe you find some problems on the upgrade scripts, but it's easier to fix them than fix the problems regarding model/eav's problems on the fly.
I have succeed by doing this on migrate from 1.4.1 to 1.8.1.