I run Oracle Database 12.2.0.1 from official dockerfile. As far as I see, if I do
docker stop <container_id>
the current state of the database is lost and next time it will do some clean start.
How to shutdown the database correctly and stop the container, but save the current state?
If I do
./sqlplus sys as sysdba
SHUTDOWN IMMEDIATE
the container remains running and still consumes 11GB of 16GB of RAM, so as far as I guess, to stop the container I should probably kill some process, but it is not clear when should I do
docker commit <container_id>
so ideally I need something like shutdown_oracle_and_commit_container.sh.
Inside the docker container the oracle instance is started with runOracle.sh, but there is no stopOracle.sh
You should use a docker volume to store the data from your database outside your container. Therefore use the -v option and mount any path you like to store your data to /opt/oracle/oradata inside the container.
From the docs:
-v /opt/oracle/oradata
The data volume to use for the database.
Has to be writable by the Unix "oracle" (uid: 54321) user inside the container!
If omitted the database will not be persisted over container recreation.
So according to that run:
docker run -v /path/to/your/datastore/:/opt/oracle/oradata oracle/database
The data from your database are now stored outside the container. If you use docker stop <container_id> or even docker rm <container_id> and you recreate a container again your data will be the same. For more information and configuration parameters see the docs.
To shutdown the DB inside docker container, first
get into container in interactive mode, by executing:
docker exec -it <name> /bin/bash
if you made it with default name, <name> = myxedb
start sqlplus and login to your DB (as sysdba)
sqlplus /nolog
conn sys/***#<db> as sysdba
in my case, <db> = //localhost:1521/XE
issue the shutdown process
shutdown immediate
That's it.
Related
Sometimes the Docker container where Memgraph is running just stops working or says that the process was aborted with exit code 137. How can I fix this?
You should check the Memgraph logs, where you'll probably find the reason why the process was aborted.
Since you said that you're using Memgraph with Docker, there are two options:
If you run Memgraph with Docker using the volume for logs, that is with
-v mg_log:/var/log/memgraph, then mg_log folder usually can be found at \\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\ (Windows) or /var/lib/docker/volumes/ (Linux and macOS).
If you run Memgraph without using the volume for logs, then you need to enter the Docker container. In order to do that, first you have to find out the container ID by running docker ps. Then you have to copy the container ID and run docker exec -it <containerID> bash. For example, if container ID is 83d76fe4df5a, then you run docker exec -it 83d76fe4df5a bash. Next, you need find the folder where logs are located. You can do that by running cd /var/log/memgraph. To read the logs, run cat <memgraph_date>.log, that is, if you have log file memgraph_2022-03-02.log located inside the log folder, then run cat memgraph_2022-03-02.log.
Hopefully, when you read the logs, you'll be able to fix your problem.
I installed oracle db version 19c in my docker environment with the following command:
docker run --name oracle19c --network host -p 1521:1521 -p 5500:5500
-v /opt/oracle:/u01/oracle oracle/database:19.3.0-ee
Then I connect to it with:
docker exec -ti oracle19c sqlplus system/oracle#orclpdb1
SQL>
Then I setup my database. Afterwards I want to import dummy data from a tbl file so I exit sqlplus and I use the command:
sqlldr userid=system control=/home/userhere/sql_loader/control.ctl log=sf1customer.log
and get sqlldr: not found
I don't have much experience with Docker, but my research leads to me to believe that SQL *Loader does not come with the docker image. However, I do not know how to extend the image or where exactly I would call SQL *Loader even if I did. I am on a Ubuntu server and any help would be appreciated.
SQL*Loader is in the image - but the docker container is separate from your host OS, so ubuntu doesn't know any of the files or commands inside it exist. Any commands inside the container should be run as docker commands. If you try this, it should connect to your running container and print the help page:
docker exec -ti oracle19c sqlldr
Since you're running this command on the docker container, sqlldr doesn't have access to any of your host OS's files unless you specifically granted them to the container. But good news - when you started the database with docker run, that's what the -v /opt/oracle:/u01/oracle part of the command did - it mapped /opt/oracle on your Ubuntu filesystem to /u01/oracle in the docker container. So any files that you put in /opt/oracle will be available in the container under /u01/oracle.
So you'll need to do a couple things:
Your control.ctl file, log file, and whatever data file you're using need to be accessible to the container. Either move them to /opt/oracle or shutdown your database container and restart it with something like -v /home/userhere/sql_loader:/u01/oracle in the command.
You might also need to edit your control.ctl file to make sure that it doesn't reference any file paths on your host OS. Either use relative paths (./myfile.csv) or absolute paths with the container's filesystem (/u01/oracle/myfile.csv)
Now you should be able to run sqlldr on the container, and it should be able to access your data files.
docker exec -ti oracle19c sqlldr userid=system control=/u01/oracle/control.ctl log=/u01/oracle/sf1customer.log
Edit: Oh, I should mention - as an alternative, if you download and install the Oracle Instant Client in Ubuntu, you could run sqlldr locally in Ubuntu, and connect to the docker container over the network as a "remote" database:
sqlldr system#localhost:1521/orclpdb1 control=/home/userhere/sql_loader/control.ctl log=sf1customer.log
That way you don't have to move your files anywhere.
I able to run Flask API container successfully. But during the app execution it fails and stops the container for some reason.
I do checked container logs and noticed some file missing error is coming. Now I want to debug what file is missing by accessing /bin/bash of stopped container. But it throws an error saying container is not running.
docker exec -it CONTAINER /bin/bash
Is there any workaround to access bash in the STOPPED container?
No, you cannot.
However, it might be useful to either check the logs or specify bash as an entry point when doing a docker run
Checking logs: https://docs.docker.com/config/containers/logging/
docker logs <CONTAINER_NAME>
Shell Entry point: https://docs.docker.com/engine/reference/run/#entrypoint-default-command-to-execute-at-runtime
docker run --name <CONTAINER_NAME> --entrypoint /bin/bash <IMAGE_NAME>
If you container does not have /bin/bash, try
docker run --name <CONTAINER_NAME> --entrypoint /bin/sh <IMAGE_NAME>
You can try to use the docker commit command.
From the docs:
It can be useful to commit a container’s file changes or settings into
a new image. This allows you to debug a container by running an
interactive shell, or to export a working dataset to another server.
Resource with a example:
We can transform a container into a Docker image using the commit
command. All we need to know is the name or the identifier of the
stopped container. (You can get a list of all stopped containers with
docker ps -a).
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
0dfd54557799 ubuntu "/bin/bash" 25 seconds ago Exited (1) 4 seconds ago peaceful_feynman
Having the identifier 0dfd54557799 of the stopped container, we can
create a new Docker image. The resulting image will have the same
state as the previously stopped container. At this point, we use
docker run and overwrite the original entrypoint to get a way into the
container.
# Commit the stopped image
docker commit 0dfd54557799 debug/ubuntu
# now we have a new image
docker images list
REPOSITORY TAG IMAGE ID CREATED SIZE
debug/ubuntu <none> cc9db32dcc2d 2 seconds ago 64.3MB
# create a new container from the "broken" image
docker run -it --rm --entrypoint sh debug/ubuntu
# inside of the container we can inspect - for example, the file system
$ ls /app
App.dll
App.pdb
App.deps.json
# CTRL+D to exit the container
# delete the container and the image
docker image rm debug/ubuntu
You can't because this container is dead as well as turned down virtual machine is dead. You can check logs using docker logs command.
docker container ls -aq
docker logs <name_of_your_dead_container>
From the man pages from docker-run:
--entrypoint=""
Overwrite the default ENTRYPOINT of the image
So use something like:
docker run --entrypoint=/usr/bin/sleep 1000 ......
This will start the container and wait 1000 seconds, allowing you to connect and debug.
From windows, I connected to Postgres Docker container from the local machine. But I can't see the tables that are existed in postgres container. The data is not replicating locally. I followed this tutorial
for running the postgres container on windows.
I managed to create the tables from dump file.
$ docker volume create --name postgres-volume
$ docker run -p 5432:5432 --name postgres_db -e POSTGRES_PASSWORD=password -v postgres-volume:/var/lib/postgresql/data -d postgres
$ docker exec -it <container-id> bash -c "pg_dump -h <source-url> -U postgres -d postgres > /tmp/dump.sql"
$ docker exec -it <container-id> bash -c "psql -f /tmp/dump.sql -U postgres -d postgres"
Any help, appreciated.
Containers
Containers are meant to be an isolated instance of a program/service. They are isolated both from the host and subsequent spawns of the same image. They start off in an isolated island, with nothing in it (that it didn't bring itself). Any data they generate is lost upon their death. They are, also, completely oblivious to any data on the host (for now). But, sometimes, we want their data to be persistent or "inject" our own data each time they start up. Such as your case with PostgreSQL. We want PostgreSQL to have our schema available each time it starts up. And, it would also be great if it retained any changes we made or data we loaded.
Docker Volumes
Enter docker volumes. It is a good method to manage persistent storage for containers. They are meant to be mounted in containers and let them write their data (or read from prior instances) which will not be deleted if the container instance is deleted. Once you create a volume with docker volume create myvolume1, it'll create a directory in /var/lib/docker/volumes/ (on windows it'll be another default. Can be changed). You never have to be aware of the physical directory on your host. You only need be aware of the volume name myvolume1 (or whatever name you choose it to have).
Containers with persistent data (docker volumes)
As we said, containers, by default, are completely isolated from the host. Specifically its filesystem, too. Which means, when a container starts up, it doesn't know what's on the host's filesystem. And, when the container instance is deleted, the data it generated during its life perishes with it.
But, that'll be different if we use docker volumes. Upon a container's start-up, we can mount within it data from "outside". This data can either be the docker volume we spoke of earlier or a specific path we want (such as /home/me/somethingimport which we manage ourselves). The latter isn't a docker volume but works just the same.
Tutorial
The tutorial you linked talks about mounting both a path and a docker volume (in separate examples). This is done with the -v flag when you execute docker run. Because using docker on windows, there is an issue with permissions to the PostgreSQL data directory on the host (which is mounted in the container), they recommend using docker volumes.
This means you'll have to create your schema and load any data you need after you used a docker volume with your instance of PostgreSQL. Subsequent restarts of the container must use the same docker volume.
docker volume create --name postgres-volume
docker run -p 5432:5432 --name postgres_db -e POSTGRES_PASSWORD=password -v postgres-volume:/var/lib/postgresql/data -d postgres
From the tutorial
These are the two important lines. The first creates creates a docker volume and the second starts a fresh PostgreSQL instance. Any changes you make to that instance's data (DML DDL), will be saved in the docker volume postgres-volume. If you've previously spun up a container (for example, PostgreSQL) that uses that volume, it'll find the data just as it was left last time. In other words, what makes the second line a fresh instance is the fact that the docker volume is empty (it was just created). Subsequent instances of PostgreSQL will find the schema+data you loaded previously.
I migrated from Linux to Windows and tried to setup a postgres container with a mounted directory (copied from my Linux install) containing the database.
This does not work.
Windows mounts are always owned by root
Postgres does not run under root
How to get this unholy combination to work?
You don't provide much details so it is difficult to tell what actually went wrong. However there is a known issue with Postgres setup on Windows Docker using a windows mount for database data files. In that case, running docker logs will show something along the following lines
waiting for server to start....FATAL: data directory "/var/lib/postgresql/data" has wrong ownership
HINT: The server must be started by the user that owns the data directory.
stopped waiting
pg_ctl: could not start server
Unfortunately there is no way to overcome this issue so you cannot use Windows mount, see Postgres Data has wrong ownership. You may use docker volumes in order to make database data indipendent from docker postgres container, using the following commands
docker create -v /var/lib/postgresql/data --name PostgresData alpine
docker run -p 5432:5432 --name yourPostgres -e POSTGRES_PASSWORD=yourPassword -d --volumes-from PostgresData postgres
You may find a more thoroughful explanation at Setup Postgresql on Windows with Docker