Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

robinsonryan's avatar

artisan:mirgate hangs on production server

TLDR; I have a migration that adds a column to an existing table. The migration runs fine on one testing server and one AWS production server in Canada, but it just hangs and does nothing on our main US AWS production server. There are two migration that need to run in the deploy. The first executes correctly and the second just hangs. There are no errors in the logs and I'm hoping to get some ideas on where to look next to find the issue. Below are as many details as I can think to provide:

I am working on a codebase that has a git beta branch and a main branch. Features are developed and merged into the beta branch and automatically deployed to a beta sever where QC takes place. If the feature passes, it is pushed to the main branch and automatically deployed to two separate AWS servers (one in the US and one in Canada) via Forge and Envoyer.

My latest commit includes a simple migration that adds a column to a database table. The commit deployed flawlessly on the beta server, so I pushed it the the main branch. The deploy to the Canadian server worked, but the deploy to the US server failed because the command that runs php artisan migrate --force timed out. I retried the deploy on Envoyer and got the same result. There are no errors in any logs on AWS, Forge, or Envoyer related to command failing. Here is what else I've tried:

I cloned the repo manually and tried to run the commands manually via SSH on the server. When I run php artisan migrate --force the CLI cursor moves to the next line and then it just hangs. I've left it running to an hour and there is no output, no error, nothing. I eventually just have to ctrl+c to kill it.

The commit actually contains two separate migrations. The first one was successful. While on SSH I ran php artisan migrate:rollback to undo the successful migration. I then ran php artisan:migrate --force and the first migration ran successfully while the second behaved as described above.

I wondered if it might just be an AWS or Forge problem, so I manually rebooted the AWS server instance and the Amazon RDS instance. This had no effect on the above behavior.

There is no practical way for me to provide all of the code and all of the configurations that might help me solve this problem like I could if you were all sitting here in the room with me, but I am hoping that I can get some ideas on where to go next. Without any errors in the logs I don't know what else I can test. The migration runs fine on two other identical servers. The fact that the first migration runs on the production server, but not the second makes me think there is something going on with the actual table I'm migrating on the production server.

Anyone have any ideas on where I can go next to track this down?

Here is the code from the migration that won't run. It is probably worth noting that this table gets a large amount of data and is archived monthly. It currently has 9,323,703 rows. The Beta and Canada servers are only ever on the order of 100,000 rows.

migration_that_hangs.php

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class MigrationThatHangs extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('device_histories', function (Blueprint $table) {
            $table->boolean('medication_count')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('device_histories', function (Blueprint $table) {
            $table->dropColumn('medication_count');
        });
    }
}
0 likes
1 reply
robinsonryan's avatar

I've done some more reading and I'm pretty sure the issues has to do with the size of the table being 10 Million records. The app is running on mysql 5.7, so (I think) there is no option to instantly add the column, it has to rebuild the entire table. There are multiple columns with indexes and multiple foreign key columns, so I think the rebuild is a really long running process.

Please or to participate in this conversation.