<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Access on PIGSTY</title>
    <link>https://v27.pgsty.pro/tags/access/</link>
    <description>Recent content in Access on PIGSTY</description>
    <generator>Hugo</generator>
    <language>en-US</language>
    
    
    
      <lastBuildDate>Mon, 01 Jan 0001 00:00:00 +0000</lastBuildDate>
    
    
      <atom:link href="https://v27.pgsty.pro/tags/access/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
        <title>Services</title>
        <link>https://v27.pgsty.pro/docs/pgsql/svc/</link>
        <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
        
        <guid>https://v27.pgsty.pro/docs/pgsql/svc/</guid>
        <description>&lt;blockquote&gt;&#xA;&lt;p&gt;Split read &amp;amp; write, route traffic to the right place, and achieve stable &amp;amp; reliable access to the PostgreSQL cluster.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Service is an abstraction to seal the details of the underlying cluster, especially during cluster failover/switchover.&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;personal-user&#34;&gt;Personal User&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;Service is meaningless to personal users. You can access the database with raw IP address or whatever method you like.&lt;/p&gt;&#xA;&lt;div class=&#34;td-code td-code--untitled&#34; id=&#34;td-code-616749f4-fence-0&#34; data-td-code data-td-code-auto-id&#xA;     data-td-language=&#34;bash&#34; data-td-line-count=&#34;3&#34;&gt;&#xA;  &lt;div class=&#34;td-code__viewport&#34; id=&#34;td-code-616749f4-fence-0-viewport&#34; data-td-code-viewport&gt;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;psql postgres://dbuser_dba:DBUser.DBA@10.10.10.10/meta     &lt;span class=&#34;c1&#34;&gt;# dbsu direct connect&lt;/span&gt;&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;psql postgres://dbuser_meta:DBUser.Meta@10.10.10.10/meta   &lt;span class=&#34;c1&#34;&gt;# default business admin user&lt;/span&gt;&#xA;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;psql postgres://dbuser_view:DBUser.View@pg-meta/meta       &lt;span class=&#34;c1&#34;&gt;# default read-only user&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/div&gt;&#xA;&lt;/div&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;service-overview&#34;&gt;Service Overview&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;We utilize a PostgreSQL database &lt;strong&gt;cluster&lt;/strong&gt; based on replication in real-world production environments. Within the cluster, only one instance is the leader (primary) that can accept writes. Other instances (replicas) continuously fetch WAL from the leader to stay synchronized. Additionally, replicas can handle read-only queries and offload the primary in read-heavy, write-light scenarios. Thus, distinguishing between write and read-only requests is a common practice.&lt;/p&gt;</description>
      </item>
    
  </channel>
</rss>
