summaryrefslogtreecommitdiff
path: root/docker/mariadb/extend_start.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-08-08Support customising MariaDB log directoryDoug Szumski1-4/+6
This retains the default, but allows the directory to be customised if required. This is useful, for example, when using Kolla Ansible to deploy multiple instances of MariaDB. Partially Implements: blueprint support-nova-cells Change-Id: I042fbe140ee84f2ed72e27635be247cb145aac5f
2019-03-23MariaDB upgrade: specify host and portMark Goddard1-1/+1
While mysql_upgrade seems to work on CentOS images without specifying a host and port, it fails on Ubuntu without these. Change-Id: Ie140de57c4fe2f2e4db6a90c18e3535d9cc71ff2 Related-Bug: #1820325
2019-03-18Fix MariaDB 10.3 upgradeMark Goddard1-0/+13
There are a couple of issues with the mariadb image currently. 1. it doesn't include mysql_upgrade on CentOS/RHEL. It is necessary to run this after an upgrade of MariaDB. This is fixed by installing mariadb-server-utils. 2. it inherits the standard dumb-init entrypoint from the base image, which includes a --single-child argument. That causes signals to be forwarded only to the process executed by dumb-init, which in the case of kolla-ansible is mysqld_safe, however mysqld_safe ignores SIGTERM. After a timeout, Docker then forcibly kills the container. Executing dumb-init without --single-child ensures the TERM signal is sent to mysqld, allowing it to shutdown gracefully. Change-Id: I1a450736721863b91be1ea3d3c8948990de9fdeb Closes-Bug: #1820325
2018-01-22Add --wsrep-new-cluster option back in the bootstrap_db functionJeffrey Zhang1-1/+1
Ia2acb09e877a586243fc1acb49d8d140cf27d7b5 removed the "--wsrep-new-cluster" option and left "--wsrep-on=OFF". But it seems "--wsrep-on=OFF" won't work with mariadb 10.0. and In Ubuntu, we are still using mariadb 10.0. Try to add --wsrep-new-cluster back Change-Id: I4d382d1b9c83def62dc85a773580c8c6b2500f68
2018-01-04Fix MariaDB bootstrap for 10.1 versionXinliang Liu1-16/+2
Option "wsrep_on" behaves differently between 10.0 and 10.1 [1]: "Before MariaDB 10.1, even though this variable is ON by default, its value get automatically adjusted based on whether mandatory configurations to turn on Galera replication have been specified. Since MariaDB 10.1, it is set to OFF by default and must be turned on to enable Galera replication." So on MariaDB 10.0 although wsrep_on set to OFF, its value will automatically adjusted to ON because wsrep mandatory configurations are set. Whereas on MariaDB 10.1, it will failed at galera provider 'wsrep_ready' checking because wsrep_on is set to OFF. We can set wsrep_on to ON to handle both 10.0 and 10.1. But, the point is that the cluster bits, which are creating a cluster and wsrep_ready checking, are no need at bootstrap stage. At bootstrap stage it mainly do two things: Creating required system DBs (by mysql_install_db) and securing the mariadb (by bootstrap_db). After the bootstrap stage, it will create a cluster when starting the first node. [1] https://mariadb.com/kb/en/library/galera-cluster-status-variables/#wsrep_ready Partial-Bug: 1740060 Co-Authored-By: Steven Dake <stdake@cisco.com> Change-Id: Ia2acb09e877a586243fc1acb49d8d140cf27d7b5
2017-07-16Fixing mariadb bootstrap failure in kolla-kubernetesSerguei Bezverkhi1-1/+1
With latest master, mariadb is failing to bootstrap in kolla-kubernetes cluster. The issue is with the name of mysql pid file. When it is not forced in the command line, in kolla kubernetes it gets created in the form of mariadb-init-element-xqg4b.pid where mariadb-init-element-xqg3b is pod name, but bootstrap scripts explicitely checks for mysql.pid. Change-Id: Ic0ee577d73d196ef40354efa51ca3ba60bf4e125 Closes-Bug: #1704671
2017-05-26Remove sudo operations that are no longer necessarySteven Dake1-5/+0
set_configs.py has logic to handle chown of directories. Simplify the codebase by removing these unnessary chowns. Further the chowns cause some forms of NFS backed storage to not work properly. Change-Id: I8df95d06b1010778deb3e2a3065aaab26ed2eb6a Closes-Bug: #1693973
2017-03-27check mariadb galera status in every loop.huweihua1-0/+1
in extend_start.sh, if Mariadb galera is not ready at first time, it will sleep 60s and then exit 1. we should check it`s status every time in the loop. Change-Id: I89174969687eecbf467ca3cad9aad1bfbfb8c4fe Closes-Bug: #1676316
2016-12-31Disable networking during bootstrappingSam Yaple1-1/+1
There is no reason to have networking active while bootstrapping the initial mysql folder structure. It is an additional attack vector that serves no purpose. Change-Id: Ia636ba9f563dbfb969dbfb613198c98748ee8a3c
2016-11-07Wait the wsrep_ready to be ON in mariadbJeffrey Zhang1-1/+1
Mariadb galera will be ready only when wsrep_ready to be ON, rather then wsrep_cluster_status is equal to Primary. Closes-Bug: #1639838 Change-Id: I9ef60a39a195057eeee0404a39b174cc8feed793
2016-09-14Mariadb bootstrap - no need to check for cluster ready in KubeSerguei Bezverkhi1-29/+14
The change c7c87909 has introduced an unconditional check for wsrep cluster during bootstrap process whether is ready or not and if it is not, bootstrap fails. In kubernetes environment wsrep driver is set to none, cluster will NEVER reach ready state hence causing kubernetes mariadb bootstrap job failure. Closes-Bug: #1623662 Change-Id: I0e6fc098861b7eeab544229d0b04a78fa498ddb9
2016-09-13Fix mariadb bootstrap errorHui Kang1-1/+16
Wait until the mariadb cluster is fully functional - check existence of mariadb.pid is insufficient because the cluster may not be fully prepared Change-Id: I611b38f7dbc8032c42aee2a040fb1210b4bee7eb closes-bug: #1614363
2016-06-05Add kolla-kubernetes bootstrap capability to mariadbRyan Hallisey1-0/+18
Kolla-kubernetes requires there be an alternative way to bootstrap the container. Kolla-kubernetes uses the Kubernetes API endpoint to read information about the cluster so that the bootstrap process runs serially. Partially-implements: blueprint kolla-kubernetes-extended-dockerfiles Change-Id: I6185f2522b1151c934871a1ad2387f0001c0a320 Co-authored-by: Ken Wronkiewicz <wh-openstack@wirewd.com>
2016-03-21Fix mysql bootstrapSamYaple1-2/+6
The lightsout recover patch broke multinode mysql. Also the lightsout recovery didnt probably pass the --wsrep-new-cluster flag. This updates the mariadb bootstrap to work with multinode again. Closes-Bug: #1559480 Related-Id: I903c3bcd069af39814bcabcef37684b1f043391f Change-Id: I1ec91a8b2144930ea8f04cc1c201b53712352e4e
2016-03-16MariaDB lights out recoverySamYaple1-1/+0
This playbook only matters for multinode since AIO can recover from power outage without additional configuration. DocImpact Implements: blueprint mariadb-lights-out Change-Id: I903c3bcd069af39814bcabcef37684b1f043391f
2016-02-19Make Heka collect MariaDB logsÉric Lemoine1-0/+8
Partially implements: blueprint heka Change-Id: Ib5e740683cee296bcac69228f525594850d62a27
2016-01-28Cleanup mariadb and make compatiable with mesosSamYaple1-2/+5
There is no reason to have a hostname-unique pidfile in the container as we currently have. This posed problems with kolla-mesos reusing the same script. Since there is no reason for this pidfile to be configurable in path _at_ _all_, we hardcode the path. Additionally, we adjust the file perm change to only update the perms on the folder if it is not already properly set. This also incorperates a kolla-ansible file in the bootstrap process which follows our other container techniques of using the idempotent creation of a volume in the bootstrap process (see nova) TrivialFix Related-Bug: #1538136 Change-Id: I2380529fc7146a9603145cdc31e649cb8841f7dd
2016-01-04Make galeradb bootstraping robustSidharth Surana1-5/+11
Currently, there are arbitrary wait for mariadb service startup. However, this leads to nondeterministic results in the current workflow. This patch tries to make the workflow more deterministic. Change-Id: I3c6245cce93c7ff0d3d57cb2ae065a1ed1487769 Closes-Bug: #1491782
2015-11-12Drop root privileges for mariadbSteven Dake1-4/+4
Drop root privileges for mariadb. This isn't perfect. If somemone breaks out of the container and can run sudo within the contianer, it would be possible to replace the root credentials of the database. Any container that uses sudo suffers from some extra attack vector related to the sudo command. That said, the sudo commands are locked down to minimize harm. Change-Id: I4b3573725d940bb8aa90d43a6235d8cf7d30fc64 Partially-Implements: blueprint drop-root
2015-11-11Move the mariadb expect code to a scriptSteven Dake1-20/+1
Atleast in a script, sudo can be made to only allow the script to run from the mysql process in the future, versus all the proceesses being able to be executed as root presently. Change-Id: I030b57086e37e4dc8f668f98c04335d94ab9d2b0 Partially-Implements: blueprint drop-root
2015-10-06Common start.shSam Yaple1-0/+42
The majority of the start.sh code is identical. This removes that duplicate code while still maintaining the ability to call code in a specific container. The start.sh is moved into /usr/local/bin/kolla_start in the container The extend_start.sh script is called by the kolla_start script at the location /usr/local/bin/kolla_extend_start . It always exists because we create a noop kolla_extend_start in the base directory. We override it with extend_start.sh in a specific image should we need to. Of note, the neutron-agents container is exempt from this new structure due to it being a fat container. Additionally, we fix the inconsistent permissions throughout. 644 for repo files and the scripts are set to 755 via a Docker RUN command to ensure someones local perm change won't break upstream containers. Change-Id: I7da8d19965463ad30ee522a71183e3f092e0d6ad Closes-Bug: #1501295
generated by cgit v1.2.3 (git 2.39.1) at 2026-11-05 21:16:21 +0000