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.
laravel amazon-web-services amazon-ec2
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.
laravel amazon-web-services amazon-ec2
I haven't used Laravel with AWS butphp artisan:migrate
relies on amigrations
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 amigrations
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.
laravel amazon-web-services amazon-ec2
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
laravel amazon-web-services amazon-ec2
edited Nov 13 '18 at 15:07
thitami
asked Nov 13 '18 at 14:34
thitamithitami
398728
398728
I haven't used Laravel with AWS butphp artisan:migrate
relies on amigrations
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 amigrations
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 butphp artisan:migrate
relies on amigrations
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 amigrations
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
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
@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!
2
Thanks for the great suggestions, @Paras! I have applied theleader_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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
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!
2
Thanks for the great suggestions, @Paras! I have applied theleader_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!
2
Thanks for the great suggestions, @Paras! I have applied theleader_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!
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
ParasParas
5,720935
5,720935
2
Thanks for the great suggestions, @Paras! I have applied theleader_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 theleader_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
2
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 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 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 |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I haven't used Laravel with AWS but
php artisan:migrate
relies on amigrations
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