Os bancos de dados do grupo de disponibilidade em uma réplica secundária são definidos automaticamente como somente leitura pelo AG?

Eu daria uma boa leitura aos documentos . Particularmente a seção sobre réplicas de disponibilidade .

Cada réplica de disponibilidade recebe uma função inicial - a função primária ou a função secundária, que é herdada pelos bancos de dados de disponibilidade dessa réplica. A função de uma determinada réplica determina se ela hospeda bancos de dados de leitura/gravação ou bancos de dados somente leitura. Uma réplica, conhecida como réplica primária, recebe a função primária e hospeda bancos de dados de leitura e gravação, conhecidos como bancos de dados primários. Pelo menos uma outra réplica, conhecida como réplica secundária, recebe a função secundária. Uma réplica secundária hospeda bancos de dados somente leitura, conhecidos como bancos de dados secundários.

Como pode ser visto acima, cada réplica pode ser somente leitura ou leitura-gravação (secundária ou primária, respectivamente). Além disso, só pode haver uma réplica primária (leitura-gravação). Quando nos referimos a réplica a esse respeito, estamos nos referindo ao nível do banco de dados. Cada servidor pode hospedar vários grupos de disponibilidade, com configuração primária-secundária potencialmente mista.

A situação à qual você está se referindo com várias réplicas de leitura/gravação não é compatível com Grupos de Disponibilidade AlwaysOn, que são projetados para atender às necessidades de Alta Disponibilidade e Escala de Leitura, não configurações de vários mestres. Você deve analisar as tecnologias de replicação bidirecional para dar suporte a essa necessidade.

Quanto à configuração somente leitura em si, ela é definida automaticamente pelo grupo de disponibilidade, embora valha a pena dizer que não é a mesma configuração que a configuração "Database Read-Only" encontrada nas propriedades do banco de dados (ou is_read_onlyem sys.databases), nem é tem a mesma configuração que a opção somente leitura no nível do grupo de arquivos.

Eu aceitei a resposta de George porque ele me apontou diretamente para os documentos que afirmam que os bancos de dados AG em um secundário serão somente leitura (ou seja, por design do sistema AG pela MS).

No entanto, nos últimos detalhes da pergunta sobre a qual falei ALTER DATABASE dbName SET READ_ONLYe George esclareceu que é uma configuração diferente do que significa o AG definindo a função de um Secundário como somente leitura e, por extensão, todos os DBs nesse AG nesse Secundário.

Eu investiguei isso mais a fundo e descobri que você pode verificar a diferença entre uma falha de atualização devido ao fato de o banco de dados fazer parte de um AG em um secundário e devido à propriedade somente leitura em relação ao banco de dados (que é definida com o SQL acima).

Abaixo está um script que demonstra como set read_onlye set read_writeafeta sys.databases.is_read_only- mas, mais especificamente, mostra que você recebe uma mensagem de erro ligeiramente diferente se tentar atualizar um banco de dados protegido por essa propriedade, em vez de estar em um Secundário em um AG .

O SQL a seguir cria um novo banco de dados que será automaticamente de leitura/gravação e não fará parte de nenhum AG, mesmo que criado em uma réplica que esteja atuando como Secundária em algum AG.

Observe o comentário que fornece a mensagem de erro quando você tenta atualizar uma tabela enquanto o banco de dados está definido para read_only- em particular, a parte:

• Estado 1

Isso é diferente do erro na pergunta do post original, que mostrava

• Estado 2

Um artigo em outro lugar cita o MS Books Online para esclarecer a finalidade desse valor:

Um número de um a três dígitos com um valor máximo de 127 que indica aos engenheiros e desenvolvedores de suporte da Microsoft a localização no código do SQL Server que gerou a mensagem

Em outras palavras, o erro "Falha ao atualizar o banco de dados "X" porque o banco de dados é somente leitura" pode se originar de pelo menos duas condições diferentes: Estado 1 = propriedade do banco de dados definida como read_only(visível em sys.databases.is_read_only) e Estado 2 = parte de um AG e em uma réplica atualmente atuando como Secundária.

create database CLRTEST;
go

use CLRTEST;
go

create table CLRTEST.dbo.testTable (id int);
go

SELECT name, is_read_only FROM sys.databases where name = 'CLRTEST';
go -- Value 0 means we can read and write

SELECT * FROM fn_my_permissions(null, 'DATABASE') where permission_name = 'insert' ORDER BY subentity_name, permission_name ;  
go -- We have insert permission in the database

SELECT * FROM fn_my_permissions('testTable', 'OBJECT') where permission_name = 'insert' ORDER BY subentity_name, permission_name;
go -- We have insert permission on the table

insert into CLRTEST.dbo.testTable values (1);
go -- insert succeeds

alter database CLRTEST set read_only; -- Does change sys.databases.is_read_only to 1
go -- we set database to read-only

SELECT name, is_read_only FROM sys.databases where name = 'CLRTEST';
go -- value 1 shows database is now read-only

SELECT * FROM fn_my_permissions(null, 'DATABASE') where permission_name = 'insert' ORDER BY subentity_name, permission_name;
go -- ! but we still have insert permission in the database

SELECT * FROM fn_my_permissions('testTable', 'OBJECT') where permission_name = 'insert' ORDER BY subentity_name, permission_name;
go -- ! and we still have insert permission on the table

insert into CLRTEST.dbo.testTable values (2);
go -- ! but insert fails, with message below

-- Produces message:
-- Msg 3906, Level 16, State 1, Line 22
-- Failed to update database "CLRTEST" because the database is read-only.

alter database CLRTEST set read_write with no_wait;
go -- we set database to read-write

SELECT name, is_read_only FROM sys.databases where name = 'CLRTEST';
go -- value 0 shows database is read-write

SELECT * FROM fn_my_permissions(null, 'DATABASE') where permission_name = 'insert' ORDER BY subentity_name, permission_name ;  
go -- permissions same as all the way through this test

SELECT * FROM fn_my_permissions('testTable', 'OBJECT') where permission_name = 'insert' ORDER BY subentity_name, permission_name;
go -- permissions same as all the way through this test

insert into CLRTEST.dbo.testTable values (3);
go -- and we can insert again, as expected

use master;
go

drop database CLRTEST;
go