EC2: Laravel migrations run as many times as the instances

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.

– Sheng Slogar
Nov 13 '18 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.

– thitami
Nov 14 '18 at 9:38

add a comment |

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.

– Sheng Slogar
Nov 13 '18 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.

– thitami
Nov 14 '18 at 9:38

add a comment |

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

laravel amazon-web-services amazon-ec2

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

edited Nov 13 '18 at 15:07

asked Nov 13 '18 at 14:34

thitami

398828

asked Nov 13 '18 at 14:34

thitami

398828

asked Nov 13 '18 at 14:34

thitami

398828

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.

– Sheng Slogar
Nov 13 '18 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.

– thitami
Nov 14 '18 at 9:38

add a comment |

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.

– Sheng Slogar
Nov 13 '18 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.

– thitami
Nov 14 '18 at 9:38

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.

– Sheng Slogar
Nov 13 '18 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.

– thitami
Nov 14 '18 at 9:38

add a comment |

1 Answer
1

active

oldest

votes

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53283329%2fec2-laravel-migrations-run-as-many-times-as-the-instances%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

add a comment |

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

add a comment |

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

edited Nov 14 '18 at 16:16

answered Nov 13 '18 at 19:30

Paras

5,7401035

answered Nov 13 '18 at 19:30

Paras

5,7401035

answered Nov 13 '18 at 19:30

Paras

5,7401035

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

add a comment |

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.

– thitami
Nov 14 '18 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)

– Paras
Nov 14 '18 at 16:16

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Ndtyjky