Re: Building MySQL 5.7 From Source on Windows
From: Jerry Stuckle <jstucklex_at_attglobal.net>
Date: Fri, 18 Oct 2019 17:14:25 -0400
Message-ID: <qod9v4$nno$1_at_jstuckle.eternal-september.org>
>>> Jerry Stuckle <jstucklex_at_attglobal.net> wrote in news:qoalhr$q7l$1
>>> _at_jstuckle.eternal-september.org:
>>>> Look at your error log. Something is stopping it from opening the
>>>> port.
>>>> It could be a lot of things. Without the log it's only a guess.
>>>
>>> Below is the entirety of the error log. When the mysqld processes
>>> reaches that point, it simply does not progress any farther. It
>>> doesn't fail; it appears to hang.
>>>
>>>
>>> 2019-10-17T22:20:53.465922Z 0 [Warning] option 'net_buffer_length':
>>> unsigned value 209715200 adjusted to 1048576
>>> 2019-10-17T22:20:53.465991Z 0 [Warning] 'NO_ZERO_DATE',
>>> 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should
>>> be used with strict mode. They will be merged with strict mode in a
>>> future release. 2019-10-17T22:20:53.469628Z 0 [Note] bin\mysqld
>>> (mysqld 5.7.28-log) starting as process 5800 ...
>>> 2019-10-17T22:20:53.482179Z 0 [Note] InnoDB: Mutexes and rw_locks use
>>> Windows interlocked functions
>>> 2019-10-17T22:20:53.483425Z 0 [Note] InnoDB: Uses event mutexes
>>> 2019-10-17T22:20:53.484214Z 0 [Note] InnoDB: _mm_lfence() and
>>> _mm_sfence() are used for memory barrier
>>> 2019-10-17T22:20:53.485401Z 0 [Note] InnoDB: Compressed tables use
>>> zlib 1.2.11
>>> 2019-10-17T22:20:53.486397Z 0 [Note] InnoDB: Adjusting
>>> innodb_buffer_pool_instances from 8 to 1 since
>>> innodb_buffer_pool_size is less than 1024 MiB
>>> 2019-10-17T22:20:53.488865Z 0 [Note] InnoDB: Number of pools: 1
>>> 2019-10-17T22:20:53.490097Z 0 [Note] InnoDB: Not using CPU crc32
>>> instructions
>>> 2019-10-17T22:20:53.495533Z 0 [Note] InnoDB: Initializing buffer
>>> pool, total size = 256M, instances = 1, chunk size = 128M
>>> 2019-10-17T22:20:53.515671Z 0 [Note] InnoDB: Completed initialization
>>> of buffer pool
>>> 2019-10-17T22:20:53.546661Z 0 [Note] InnoDB: Highest supported file
>>> format is Barracuda.
>>> 2019-10-17T22:20:53.552589Z 0 [Note] InnoDB: Log scan progressed past
>>> the checkpoint lsn 1209961
>>> 2019-10-17T22:20:53.553989Z 0 [Note] InnoDB: Doing recovery: scanned
>>> up to log sequence number 1209970
>>> 2019-10-17T22:20:53.555315Z 0 [Note] InnoDB: Database was not
>>> shutdown normally!
Date: Fri, 18 Oct 2019 17:14:25 -0400
Message-ID: <qod9v4$nno$1_at_jstuckle.eternal-september.org>
On 10/17/2019 9:29 PM, Lyle H. Gray wrote:
> Jerry Stuckle <jstucklex_at_attglobal.net> wrote in > news:qoauck$a0t$1_at_jstuckle.eternal-september.org: > >> On 10/17/2019 6:23 PM, Lyle H. Gray wrote:
>>> Jerry Stuckle <jstucklex_at_attglobal.net> wrote in news:qoalhr$q7l$1
>>> _at_jstuckle.eternal-september.org:
>>>> Look at your error log. Something is stopping it from opening the
>>>> port.
>>>> It could be a lot of things. Without the log it's only a guess.
>>>
>>> Below is the entirety of the error log. When the mysqld processes
>>> reaches that point, it simply does not progress any farther. It
>>> doesn't fail; it appears to hang.
>>>
>>>
>>> 2019-10-17T22:20:53.465922Z 0 [Warning] option 'net_buffer_length':
>>> unsigned value 209715200 adjusted to 1048576
>>> 2019-10-17T22:20:53.465991Z 0 [Warning] 'NO_ZERO_DATE',
>>> 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should
>>> be used with strict mode. They will be merged with strict mode in a
>>> future release. 2019-10-17T22:20:53.469628Z 0 [Note] bin\mysqld
>>> (mysqld 5.7.28-log) starting as process 5800 ...
>>> 2019-10-17T22:20:53.482179Z 0 [Note] InnoDB: Mutexes and rw_locks use
>>> Windows interlocked functions
>>> 2019-10-17T22:20:53.483425Z 0 [Note] InnoDB: Uses event mutexes
>>> 2019-10-17T22:20:53.484214Z 0 [Note] InnoDB: _mm_lfence() and
>>> _mm_sfence() are used for memory barrier
>>> 2019-10-17T22:20:53.485401Z 0 [Note] InnoDB: Compressed tables use
>>> zlib 1.2.11
>>> 2019-10-17T22:20:53.486397Z 0 [Note] InnoDB: Adjusting
>>> innodb_buffer_pool_instances from 8 to 1 since
>>> innodb_buffer_pool_size is less than 1024 MiB
>>> 2019-10-17T22:20:53.488865Z 0 [Note] InnoDB: Number of pools: 1
>>> 2019-10-17T22:20:53.490097Z 0 [Note] InnoDB: Not using CPU crc32
>>> instructions
>>> 2019-10-17T22:20:53.495533Z 0 [Note] InnoDB: Initializing buffer
>>> pool, total size = 256M, instances = 1, chunk size = 128M
>>> 2019-10-17T22:20:53.515671Z 0 [Note] InnoDB: Completed initialization
>>> of buffer pool
>>> 2019-10-17T22:20:53.546661Z 0 [Note] InnoDB: Highest supported file
>>> format is Barracuda.
>>> 2019-10-17T22:20:53.552589Z 0 [Note] InnoDB: Log scan progressed past
>>> the checkpoint lsn 1209961
>>> 2019-10-17T22:20:53.553989Z 0 [Note] InnoDB: Doing recovery: scanned
>>> up to log sequence number 1209970
>>> 2019-10-17T22:20:53.555315Z 0 [Note] InnoDB: Database was not
>>> shutdown normally!
>> Well, start by getting rid of the errors and warnings. For instance - >> did you run mysql_upgrade as indicated? Did you follow the directions >> when upgrading MySQL? > > This is a new installation, not an upgrade. > > I should back up a step -- I don't believe that I was able to initialize > the environement. When I tried, this is what is written to the error > log: > > --- > 2019-10-18T00:05:59.604872Z 0 [Warning] option 'net_buffer_length': > unsigned value 209715200 adjusted to 1048576 > 2019-10-18T00:05:59.604976Z 0 [Warning] 'NO_ZERO_DATE', > 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be > used with strict mode. They will be merged with strict mode in a future > release. > 2019-10-18T00:05:59.987825Z 0 [Warning] InnoDB: New log files created, > LSN=45790 > 2019-10-18T00:06:00.056571Z 0 [Warning] InnoDB: Creating foreign key > constraint system tables. > 2019-10-18T00:06:00.134523Z 0 [Warning] No existing UUID has been found, > so we assume that this is the first time that this server has been > started. Generating a new UUID: 10f487b0-f13b-11e9-91b5-1065303827d4. > 2019-10-18T00:06:00.146312Z 0 [Warning] Gtid table is not ready to be > used. Table 'mysql.gtid_executed' cannot be opened. > --- > > And nothing else. The initialization hangs at that point. >
[Quoted] OK, then how did you install the initial tables? If it was from an installation package, did the installation run to completion with no problems?
And are you sure you've never tried to install MySQL (or MariaDB) on this machine before? Even a failed install can leave remnants of the base tables. This could also be true for files which may have been placed in your c:\windows directory hierarchy.
-- ================== Remove the "x" from my email address Jerry Stuckle jstucklex_at_attglobal.net ==================Received on Fri Oct 18 2019 - 23:14:25 CEST