You are not logged in.
Pages: 1
I can't even initialize mysql (nither maria nor pecona). I even bought the linode vps to test it on clear installation - same crap.
here's some logs
with maria
$ sudo mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for betrayer:
Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
2017-06-17 6:52:22 139891060072384 [Note] /usr/sbin/mysqld (mysqld 10.1.24-MariaDB) starting as process 6923 ...
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: The InnoDB memory heap is disabled
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Compressed tables use zlib 1.2.11
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Using Linux native AIO
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Using SSE crc32 instructions
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Completed initialization of buffer pool
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2017-06-17 6:52:22 139891060072384 [Warning] InnoDB: New log files created, LSN=45883
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Doublewrite buffer not found: creating new
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Doublewrite buffer created
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: 128 rollback segment(s) are active.
2017-06-17 6:52:22 139891060072384 [Warning] InnoDB: Creating foreign key constraint system tables.
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Foreign key constraint system tables created
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Creating tablespace and datafile system tables.
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Tablespace and datafile system tables created.
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Waiting for purge to start
2017-06-17 6:52:22 139891060072384 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.0 started; log sequence number 0
2017-06-17 6:52:22 139890451293952 [Note] InnoDB: Dumping buffer pool(s) not yet started
2017-06-17 6:52:22 139891059297024 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1146: Table 'mysql.gtid_slave_pos' doesn't exist
170617 6:52:25 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.1.24-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 137013 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x48400
^X^Z
[1]+ Stopped sudo mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysqlwith percona
$ sudo mysqld --initialize
2017-06-17T06:56:13.042306Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2017-06-17T06:56:13.042382Z 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.
2017-06-17T06:56:13.042394Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2017-06-17T06:56:13.262887Z 0 [Warning] InnoDB: New log files created, LSN=45790
2017-06-17T06:56:13.308764Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2017-06-17T06:56:13.365819Z 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: 0d38f5de-532a-11e7-9349-f23c91fb8a47.
2017-06-17T06:56:13.367241Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2017-06-17T06:56:13.368026Z 1 [Note] A temporary password is generated for root@localhost: -xraJ4*zv#Mo
06:56:15 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=152
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68317 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x36)[0x55bf8e0d9ab6]
mysqld(handle_fatal_signal+0x49b)[0x55bf8d9eab4b]
/usr/lib/libpthread.so.0(+0x11940)[0x7f49bfb27940]
/usr/lib/libjemalloc.so.2(+0x584d3)[0x7f49c09f54d3]
/usr/lib/libjemalloc.so.2(+0x585cd)[0x7f49c09f55cd]
/usr/lib/libjemalloc.so.2(+0x5a7d8)[0x7f49c09f77d8]
/usr/lib/libpthread.so.0(+0x63c8)[0x7f49bfb1c3c8]
/usr/lib/libpthread.so.0(+0x735d)[0x7f49bfb1d35d]
/usr/lib/libc.so.6(clone+0x3f)[0x7f49befac25f]
You may download the Percona Server operations manual by visiting
http://www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.I read a bunch of stuff about this thing but seems like i'm all thumbs.
Offline
I have a very similar problem that only occurred in the past few days. I don't have a solution, but some tidbits I found that might be helpful for somebody.
I found this on the MySQL site: [1]
mysql_install_db is deprecated as of MySQL 5.7.6 because its functionality has been integrated into mysqld, the MySQL server. To initialize a MySQL installation, invoke mysqld with the --initialize or --initialize-insecure option.
However, Arch ships Mariadb, not MySQL. Mariadb does not seem to know an --initialize option (yet?). And the deprecated mysql_install_db crashes. Coincidentally (?) the mysqld.service file shipped by Arch also does not run mysql_install_db -- the ExecStartPre is commented out.
Something botched in some update between MySQL and Mariadb and the Arch package maintainer?
This observation is in conflict with the first I'm afraid. But: I'm actually running UBOS, an Arch derivative whose most recent "yellow" release is only a few days old [2]. Think of that release as a snapshot of Arch at that time. Mariadb worked fine at that time. Now it does not. And the only differences are in the following packages:
downloading archlinux-keyring-20170611-1-any.pkg.tar.xz...
downloading glibc-2.25-3-x86_64.pkg.tar.xz...
downloading geoip-database-20170606-1-any.pkg.tar.xz...
downloading bind-tools-9.11.1.P1-1-x86_64.pkg.tar.xz...
downloading p11-kit-0.23.7-1-x86_64.pkg.tar.xz...
downloading ca-certificates-mozilla-3.31-3-x86_64.pkg.tar.xz...
downloading curl-7.54.1-1-x86_64.pkg.tar.xz...
downloading glib2-2.52.2+9+g3245eba16-1-x86_64.pkg.tar.xz...
downloading gnupg-2.1.21-3-x86_64.pkg.tar.xz...
downloading jemalloc-5.0.0-2-x86_64.pkg.tar.xz...
downloading libusb-1.0.21-2-x86_64.pkg.tar.xz...
downloading mkinitcpio-busybox-1.25.1-2-x86_64.pkg.tar.xz...
downloading pacman-5.0.2-1-x86_64.pkg.tar.xz...
downloading perl-dbd-mysql-4.042-1-x86_64.pkg.tar.xz...
downloading python2-requests-2.18.1-1-any.pkg.tar.xz...I have not analyzed this in more detail (about to go to sleep) but only very few of those packages should make any difference whatsoever to mariadb.
To reproduce working:
run UBOS yellow on Amazon EC2: http://ubos.net/quickstart/
sudo ubos-admin install (enter "gladiwashere" as an app -- it uses mariadb)
observation: works just fine
To reproduce broken:
run UBOS yellow on Amazon EC2: http://ubos.net/quickstart/
edit /etc/pacman.conf and change the release channel from "yellow" to "dev" (has Arch updates since yellow release)
pacman -Sy
pacman -Su -- but do not say Yes -- just note which packages can be upgraded -- that's where the above list comes from
pacman -S <package> and choose carefully which packages to upgrade
sudo ubos-admin install (enter "gladiwashere" as an app -- it uses mariadb)
takes forever and ultimately fails.
journalctl is your friend
[1] https://dev.mysql.com/doc/refman/5.7/en … ll-db.html
[2] http://ubos.net/blog/2017/06/11/beta11-available.html
Offline
Does the issue occur if you downgrade to jemalloc-4.5.0-1?
Offline
Hello, I have (had) the exact same problem with a new installation that I'm currently setting up.
Does the issue occur if you downgrade to jemalloc-4.5.0-1?
Downgrading jemalloc (from 5.0.0-2) worked for me!
Offline
Offline
Pages: 1