Trying to run db migration automagically is a path to ruin. Having multiple hosts trying to run it is one likely error; Having one host run migration while another one is reading/writing is bad. Having one host migrate, and another expect the old schema.
Just don't go there.

Ah that was it. I increased that and also had to increase the innodb_log_file_size.

What is your max_allowed_packet set to in MySQL?

Turns out that somehow the git repository got corrupted, deleting the phabricator install and getting it from git again fixed the issue.

Yeah, even the surplus stuff is off. I'd verify your entire update process. For example, my phabricator_calendar.calendar_event table looks like this:

I don't have any other ideas. It was added in that patch, then removed a few months later in rP541e3d9e. key_room doesn't exist at HEAD.

Phabricator was installed from source using git. I can't quite remember when I last updated it, but it was probably around the end of may.

Do you know when you last updated roughly? Did you install Phabricator from source?

bin/storage status should tell you if you have patches that didn't get applied.

So far, I have come up with two different approaches to this. One of the major issues with this change is that we don't have a way to just connect to an arbitrary database with Lisk. Migrations which expect to change the phabricator_pastebin database, for example, cannot use PhabricatorPaste (which tries to connect to the phabricator_paste database, which doesn't yet exist). Furthermore, theses migrations cannot use LiskRawMigrationIterator either, because there is currently no easy way to construct an AphrontDatabaseConnection which connects to an arbitrary database.

I got bored and went ahead with this.

As a possible attack on this, we could rename phabricator_pastebin to phabricator_paste first and see how awful that is.

With a fresh install on Ubuntu 15.04 I am able to reproduce this. When I ran ./bin/storage upgrade it gave me that error.

D12053 marks this as fixed. Specifically:

This might be fixed by D11224.

I think this warning is incorrect (i.e., the statement is not actually unsafe, because the autoincrement primary key can never collide).

We can't reproduce this.

Is it possible you created all the DBs listed in bin/storage databases of an old version of Phabricator?

Forgot to re-open with my previous comment.

This happens on a completely fresh install.
All I did was:

bin/storage databases does not list phabricator_timeline because it is no longer an active database. It was removed by D5744.

We aren't interested in supporting this in the upstream, since it seems like a lot of complexity and a negligible amount of value.

Well, in case of Amazon/other cloud I simply don't know or have any control over traffic between my virtual machine and RDS.
In post-Snowden world there are many other good reasons to try to wrap as much stuff as possible in ssl.

I don't think I really understand the threat model for (1) here.