Changeset 8986fa9


Ignore:
Timestamp:
12/04/2021 03:25:28 PM (7 weeks ago)
Author:
Thomas Trepl (Moody) <thomas@…>
Branches:
lazarus, trunk, upgradedb
Children:
d86ea4b
Parents:
7f6bf79b
Message:

Add bdb and sqlite

File:
1 edited

Legend:

Unmodified
Added
Removed
  • server/databases/upgradedb.xml

    r7f6bf79b r8986fa9  
    5656    of your data.
    5757  </para>
    58  
     58
    5959  <sect2>
    6060    <title>Upgrade database server packages</title>
     
    131131        <listitem>
    132132          <para>Create a full database backup using the old tools.</para>
    133           <para>This step creates an offline copy of the database 
     133          <para>This step creates an offline copy of the database
    134134          files ready to be used for long term archiving, for desaster
    135135          recovery or just as a preparation for upgrade. This offline
     
    152152          hundrets of Terabyte. A full backup of the later one isn't done
    153153          quickly (and we assume that the underlaying system of such a DB
    154           might not be a home brewed LFS anyhow).</para>
     154          might not be a home brewed LFS anyhow).
     155          To close the last gap to fully protect your data, create a backup
     156          of the corresponding old binaries (and/or their sources) and
     157          store it along with the data files to
     158          make sure that there is a fallback solution if it comes to
     159          the situation that newer software might not be able to read
     160          ancient data.</para>
    155161        </listitem>
    156162        <listitem>
    157163          <para>Upgrade the server software</para>
    158164          <para>In this step, instructions to build the database
    159           server software are executed just as they are shown in 
     165          server software are executed just as they are shown in
    160166          subsequent sections talking about the DBMs like MariaDB or
    161167          Postgresql. This is building the software as
     
    167173          server software is used. During the restore process, the new
    168174          tools will create and/or upgrade the data files in the
    169           format the software expects them to be.</para>
     175          format the software expects them to be. At this moment it is
     176          assumed that newer software is capable to read old data.</para>
    170177        </listitem>
    171178      </itemizedlist>
     
    174181        Since you have already a backup procedure in place (and you
    175182        have tested your restore procedure, don't you?), this way might
    176         be the easiest way to upgrade as you are going to use well-known
     183        be the easiest way to upgrade as you are going to use your wellknown
    177184        processes to upgrade just as you allways do - at least in terms
    178185        of the backup and restore.
     
    212219  <sect2>
    213220    <title>Notes for specific DBMS</title>
    214    
     221
    215222    <sect3>
    216223      <title>PostgreSQL</title>
    217      
     224
    218225      <!-- might add some advanced notes for the DBMS here -->
    219226
     
    221228        <ulink url="https://www.postgresql.org/docs/current/backup.html"/>
    222229      </para>
    223      
     230
    224231    </sect3>
    225232
    226233    <sect3>
    227234      <title>MariaDB</title>
    228      
     235
    229236      <!-- might add some advanced notes for the DBMS here -->
    230237
     
    232239        <ulink url="https://mariadb.com/kb/en/backup-and-restore-overview/"/>
    233240      </para>
    234      
    235     </sect3>
    236 
     241
     242    </sect3>
     243
     244    <sect3>
     245      <title>Sqlite</title>
     246
     247      <!-- might add some advanced notes for the DBMS here -->
     248
     249      <para>Don't underestimate <application>Sqlite</application>, it
     250      is a feature rich DBMS. The main difference to the two big
     251      players above is that Sqlite does not provide access via a
     252      network API. Sqlite databases are files always stored on the
     253      same machine as the running program which reads/writes the
     254      database. The manipulation of data content is done via API calls
     255      to library functions directly within the program.</para>
     256
     257      <para>In the upstream documentation you may find the
     258      following useful:</para>
     259
     260      <para>Documentation of the sqlite3 command line tool:
     261        <ulink url="https://www.sqlite.org/cli.html"/>
     262      </para>
     263      <para>Documentation of backup API calls:
     264        <ulink url="https://www.sqlite.org/backup.html"/>
     265      </para>
     266
     267      <para>Unfortunatly, there is no dedicated chapter in the
     268      upstream documentation talking about backup &amp; restore but
     269      there are several articles about it somewhere else in the
     270      Internet. One example is shown below.</para>
     271
     272      <para>Documentation for Backup &amp; Restore:
     273        <ulink url="https://database.guide/backup-sqlite-database/"/>
     274      </para>
     275
     276    </sect3>
     277
     278    <sect3>
     279      <title>Berkeley DB</title>
     280
     281      <!-- might add some advanced notes for the DBMS here -->
     282
     283      <para>Just like <application>Sqlite</application> this
     284      software acts on local database files meaning there is no
     285      network interface, too.</para>
     286
     287      <para>The relevant resources for Backup &amp; Restore a Berkeley DB
     288      are the man pages for <filename>db_dump</filename> and its
     289      counterpart <filename>db_load</filename>.</para>
     290
     291    </sect3>
    237292  </sect2>
    238  
     293
    239294</sect1>
Note: See TracChangeset for help on using the changeset viewer.