fixes (#162)

* fixes

en/data-retention/index.rst

@@ -4,7 +4,7 @@
 Data retention
 ~~~~~~~~~~~~~~
 
-Data retention should be configured for heavy loaded production systems. Yeti has built-in tools to remove historical data from databases. Such tools can be configured via **/opt/yeti-web/config/yeti_web.yml** configuration file::
+Data retention should be configured for production systems. Yeti has built-in tools to remove historical data from databases. Such tools can be configured via **/opt/yeti-web/config/yeti_web.yml** configuration file::
 
     
     partition_remove_delay:
@@ -17,5 +17,11 @@ Data retention should be configured for heavy loaded production systems. Yeti ha
 
 This configuration defines how many historical **partitions** should be saved in database for each table.
 
+To apply configuration - restart **yeti-scheduler** service:
+
+.. code-block:: console
+
+    # systemctl restart yeti-scheduler
+
 
 Admin WEB interface views :ref:`CDR -> CDR Partitions <cdr_partitions>` and :ref:`Logs -> Log partitions <log_partitions>` allows to see existing partitions in CDRs and Routing databases.

en/database-tuning.rst

@@ -5,9 +5,15 @@
 
 .. _database_tuning:
 
-============================
-Databases performance tuning
-============================
+=====================
+Databases Maintenance
+=====================
+
+Yeti switch using two postgresql databases to store routing data and CDRs. This document describes some maintenance procedures.
+
+
+Performance tuning
+==================
 
 By default PostgreSQL RDBMS configured to consume minimal system resources. This approach allows PostgreSQL to start on any server after installation. YETI as well as any other system uses PostgreSQL requires changing default configuration in order to archive best performance.
 
@@ -30,8 +36,30 @@ When configuration changed you should restart your PostgreSQL instance using `se
 
 
 
+Dump and Restore
+================
 
-
+.. TODO:  Explain why we need it
+
+See https://github.com/markokr/skytools/blob/master/doc/faq.txt#L50 for details
+
+To get know your cluster epoch, connect to database using **psql** and run:
+
+.. code-block:: psql
+
+	cdr=# SELECT (txid_current() >> 32) as epoch;
+	epoch
+	-------
+		0
+	(1 row)
+
+
+To change PostgreSQL cluster epoch - shutdown cluster and use **pg_resetwal** tool:
+
+.. code-block:: console
 
+	# su - postgres
+	$ /usr/lib/postgresql/16/bin/pg_resetwal -e 1 /var/lib/postgresql/16/cdr
 
 
+Where **1** is new epoch - it should be greater then epoch of old instance

en/installation/installation-1.13/sems.rst

@@ -252,7 +252,7 @@ Launch configured traffic switch instance:
 
 .. code-block:: console
 
-    # systemctl sems start
+    # systemctl start sems
 
 In case of errors it's useful to use **sems -E -D3** command
 which will launch daemon in foreground with debug logging level