2 to the power of 32 is 4294967296.
If you divide that by 2, you get:
(2^32/2) = 2147483648
This second value minus 1 is
2147483647 = 2^31 - 1, i.e. your value of interest.
Mathematically, it's the 8th Mersenne prime and is also equal to the hexadecimal (base 16) value
7FFF,FFFF. It's also the largest known
double Mersenne prime and (probably) the biggest of that class of number!
In databases and computing, it's the maximum size of a 32 bit
SIGNED INTEGER. The signed/unsigned INTEGER type is one of the few areas in which MySQL is superior to PostgreSQL. I think that unsigned INTEGERs have many potential uses, but then again, PostgreSQL has
CHECK CONSTARAINTs which mean that it's not obligatory to enforce positive integers as a type. Still (personal opinion), I feel it's a good type to have, if only for brevity and clarity!
Previously (in many 32 bit systems), it was the maximum number (i.e.
2147483647) of records allowed in a table and/or the maximum that an
AUTO_INCREMENTing (i.e. SERIAL or SEQUENCE) integer field could reach - but this is not now normally the case with 64 bit machines.
When this number was reached, either for the number of records, or for a key of some sort, then the behaviour of many database systems was/is either undocumented or erratic or both. The value could start again from zero (possibly breaching integrity constraints) or start at an arbitrary value or cause the system to crash completely!
On the 19th of January 2038 (at 03:14:07 UTC), there will be more than that many (
2147483647) seconds elapsed since Jan 01, 1970, i.e. the
beginning of time as far as
Unix is concerned. Aircraft will drop out of the sky, nuclear missiles will be launched without provocation and there will generally be a great wailing and gnashing of teeth - unless, of course, you're a progrmamer who can make a mint out of this (just like the COBOLers in
The Year 2038 problem relates to representing time in many digital
systems as the number of seconds passed since 1 January 1970 and
storing it as a signed 32-bit binary integer. Such implementations
cannot encode times after 03:14:07 UTC on 19 January 2038. Just like
the Y2K problem, the Year 2038 problem is caused by insufficient
capacity of the chosen storage unit.
Best to avoid completely and use 64 bit these days!