2. Memoria database update


Section “Memoria database update” contains information that you will need only in case of local Cerebro installation (see section “Local system”).

2.1. Updates – are they safe ?

Update utility performs all actions on a new separate database (after all the data from the current database is copied to the new one). At the final stage of the upgrade, current database is renamed and saved without any modifications. When all operations are completed successfully, new database will replace the existing one as your work database.

After making sure your new database works fine, you can remove old version of database, or, in case something happens, you can cancel all updates and continue working with previous configuration by renaming the old database.


Anyway, it is still recommended to have a backup plan for your databases.

Cerebro’s centralized database system is called Memoria. It functions using PostgreSQL DBMS. Memoria consists of several related tables that are accessed by pre-defined procedures stored on the server. Also Memoria has an auxiliary plug-in for PostgreSQL in order to calculate Gantt charts, manage access rights and solve licensing problems – malosol.dll/so.

2.2. Preparing for database update

Prior to running Memoria database update script you should make sure that PostgreSQL service is running on the server. Although, before or after the update you might need to temporarily stop the service to do various manipulations (replacing files, etc).

2.2.1. Stopping the PostgreSQL service


Open the Services tool. To do this, click Start, click Control Panel double-click the Administrative Tools, then Services.

Select PostgreSQL service in the list, and then select Stop in Action menu, or click the service with the right mouse button, and then select Stop from the context menu.



In the Linux perform the following command in the root console:

/etc/init.d/postgresql stop

2.2.2. Starting the PostgreSQL service


Open Services tool.

Select PostgreSQL service in the list, and then select Start in Action menu, or click the service with the right mouse button, and then select Start from the context menu.


In the Linux perform the following command in the root console:

/etc/init.d/postgresql start

2.2.3. Database file structure location

PostgreSQL database is a directory on the disk drive which contains a certain type of file structure. Configuration files are located in the top level directory. They allow you to configure various PostgreSQL parameters.

In case you already have PostgreSQL service installed, you might need to determine the location of its database. To do this, you need to know command line parameters it was launched with.


Open the Services tool. Click the PostgreSQL service in the list, right-click, and then click Properties from the context menu.


In the displayed window in the Path to executable field you can see (select and copy if needed) the service start command with all parameters.


When the PostgreSQL service is running at the background, run the following command in console:

ps afx | grep postgres

In the command output find a line that looks like the following:

/usr/lib/postgresql/9.0/bin/postgres -D /var/lib/postgresql/9.0/main -c unix_socket_directory=/var/run/postgresql -c config_file=/etc/postgresql/9.0/main/postgresql.conf

Once you have located the command to start PostgreSQL service, the following keys in it indicate the location of the database files:

  • The -D key – database file structure directory;
  • The -s key with config_file option refers to main configuration file location, that file is usually named postgresql.conf;
  • The -c key with hba_file option refers to configuration file authentication parameters location, the file is usually named pg_hba.conf.

If configuration files aren’t explicitly placed in any other location, they are located in the top level of the DB directory.

2.2.4. Disabling the external access to PostgreSQL

To successfully update Memoria database there should be no requests from Cerebro clients to the database in the process.

You can solve this by using PostgreSQL tools, limiting the range of network addresses that are allowed to connect to the database. To do this, do the following operations.


When Memoria database is finished updating, do not forget to rollback PostgreSQL access permissions, for this you should uncomment commented out lines in pg_hba.conf and restart the service.

2.2.5. Malosol plugin location

Malosol database plugin performs specialized tasks for licensing, configuring effective access rights for users and calculating parameters of linked tasks in Cerebro.

It is usually installed during Cerebro client installation.

In the case of already installed Cerebro system you can follow these steps to determine the location of Malosol file:

  • Determine the PostgreSQL launch command (see “Database file structure location”).
  • From the launch command determine PostgreSQL installation directory – it is the parent directory to bin folder, from which PostgreSQL executable file is launched.
  • Go to the lib folder within the PostgreSQL installation directory (for example, in Linux it can be /usr/lib/postgresql/9.0/lib).
  • If there is a libmalosol symbolic link in the lib directory, then by resolving it you will find out the location of your Malosol file.
  • In other case (if there’s no libalosol link in lib folder) Malosol location should be specified in the config.py script, created during the installation (see installation Cerebro manual ), in the MALOSOL variable.

2.3. Malosol plugin update

This plugin is provided as a libmalosol dynamic library inside the service-tools package (you can download it from the Download/* Server components* section on the website https://cerebrohq.com).

Malosol update is basically unpacking the libmalosol library executable file (according to database server OS) into a particular folder selected during the Cerebro installation phase (see section “Malosol plugin location”). For example, in Linux it could be /cerebro/malosol/libmalosol90-64.so.1.0.0.


To avoid shared access problems with Malosol executable file, stop the PostgreSQL (see section “Stopping the PostgreSQL service”) before replacing it and run it again after the Malosol update.

2.4. Database update

Memoria database update is executed with cerebro.db.update/internal/update.py script from service-tools package.


In order for the script to work you should have Python version 2.x or higher installed in your system (http://www.python.org) In Linux systems, Python is already installed in most cases. You need to be sure that the Python directory is added to the system path. Launch the following command to check it:

python --version

Before starting Memoria update process it is required to have a correctly configured config.py file on the server (sample of this file can be found in cerebro.db.update/config.py.example).

Usually, configuration file is tuned during Cerebro deployment phase and is placed in a specific directory:

  • For Unix-systems it’s /etc/cerebro.db.update/config.py;
  • For Windows systems it’s %APPDATA%/cerebro.db.update/config.py, where APPDATA is a system variable and represents a path like this: C:\Users\<user name>\AppData\Roaming.

In case of missing config.py file, refer to the Memoria database manual in order to create it.

2.4.1. Launching the update procedure

As mentioned above to deploy a new database it is required to run cerebro.db.update/internal/update.py Python script on the Database server. In order to run it properly you should do the following steps:

  • unpack the service-tools package to the temporary directory on your hard drive;

  • go to cerebro.db.update folder and execute the following command:

    update.<cmd|sh> <memoria-x.y>

    , i.e. pass it the name of the folder containing the image of the Memoria database from the archive as a parameter.


In order for script to work properly, PostgreSQL must be started on the server (see. section “Starting the PostgreSQL service”). It is also important that during the updating process, client modules do not send requests to the database. This can be achieved by limiting the range of network addresses that are allowed to connect to PostgreSQL (see section “Disabling the external access to PostgreSQL”).

After successful Memoria initialization, the script will display the log, ending with the word “Done!”. Otherwise, you will need to analyze the displayed error text, and try to fix these errors (usually it is lack of access rights to different objects). After you resolve all those errors, you can try updating again.


When updates to Memoria database are finished do not forget to return the access rights to the PostgreSQL to the initial state (if you were limiting the range of addresses, in accordance with section “Disabling the external access to PostgreSQL”).