Can I use MySQL instead of PostgreSQL?
Briefly: no. OpenProject has traditionally supported both MySQL and PostgreSQL, but in order to optimize for performance and SQL functionality, it is unfeasible to support both DBMS that are becoming more and more disjunct when trying to use more modern SQL features. This shift has started some years ago when full-text search was added for PostgreSQL, but at the time MySQL did not yet support it - and as of yet many distributions still do not support MySQL 8 natively.
This led us to the path of removing support in the upcoming stable releases of OpenProject in order to focus on these goals. Please see our blog post on the matter for additional notes.
/sbin/iptables -I INPUT -p tcp --dport 端口号 -j ACCEPT #开启端口
service network restart
sudo yum -y update
sudo yum -y install wget(阿里云应该是不需要执行这个)
sudo wget -O /etc/yum.repos.d/openproject-ce.repo https://dl.packager.io/srv/opf/openproject-ce/stable/8/installer/el/7.repo
sudo wget -O /etc/yum.repos.d/openproject.repo \ https://dl.packager.io/srv/opf/openproject/stable/10/installer/el/7.repo
安装OpenProject Community Edition包
添加OpenProject存储库并为OpenProject配置数据库后，在CentOS 7/Fedora 29上安装OpenProject Community Edition软件包。
sudo yum -y install openproject
$ openproject run env
$ openproject reconfigure
Scaling the number of web workers
Depending on your free RAM on your system, we recommend you raise the default number of workers. The default from 9.0.3 onwards is four worker processes. Each worker will take roughly 300-400MB RAM.
We recommend at least four workers. Please check your current worker count with
sudo openproject config:get OPENPROJECT_WEB_WORKERS
If it returns nothing, the default worker count of 4 applies. To increase or decrease the worker count, call
sudo openproject config:set OPENPROJECT_WEB_WORKERS=number
Where number is a positive number between 1 and round(AVAILABLE_RAM * 1.5).
After changing these values, call sudo openproject configure to apply it to the web server.
Backup your OpenProject installation
Note: this guide only applies if you've installed OpenProject using our DEB/RPM packages.
We advise to backup your OpenProject installation regularly — especially before upgrading to a newer version.
What should be backed up
In general the following parts of your OpenProject installation should be backed up:
Data stored in the database
Uploaded files (attachments)
Repositories (typically subversion) if applicable
How to backup
The DEB/RPM packages provide a backup tool which can be used to take a snaphsot of the current OpenProject installation. This tool will create a backup of all parts mentioned above. The backup tool is used by executing the following command:
sudo openproject run backup
The command will create backup files in the following location on your system
The content of that directory should look very similar to the following (depending on your used database, you will see a postgresql-dump-` file).
root@test-packager-backup:/opt/openproject# ls -l /var/db/openproject/backup/total 24-rw-r----- 1 openproject openproject 117 Apr 8 09:55 attachments-20150408095521.tar.gz-rw-r----- 1 openproject openproject 667 Apr 8 09:55 conf-20150408095521.tar.gz-rw-r----- 1 openproject openproject 8298 Apr 8 09:55 postgresql-dump-20150408095521.sql.gz-rw-r----- 1 openproject openproject 116 Apr 8 09:55 svn-repositories-20150408095521.tar.gz
How to restore
The backup created with the tool consists of four parts which are all compressed using gzip. Except the database dump these parts can be restored by decompressing the *.tar.gz files and copy the content to the proper location. The command to untar and unzip the *.tar.gz files looks like this (using sample file names from above):
tar vxfz attachments-20150408095521.tar.gz
The <dbuser>, <dbhost> and <dbname> variables have to be replaced with the values that are container in the DATABASE_URL setting of your installation. This setting can be seen by running:
openproject config:get DATABASE_URL#=> e.g.: postgresql://dbusername:dbpassword@dbhost:dbport/dbname
To restore the PostgreSQL dump please use the pg_restore command utilities.
pg_restore -h <dbhost> -u <dbuser> -W <dbname>
First the dump has to be extracted (unzipped) and then restored. The command used should look very similar to this:
You can find the master document in GitHub. You can propose a change to this guide by creating a pull request on GitHub.